-
1. Re: Dynamic deployments
aslak Oct 25, 2011 5:00 AM (in response to bmajsak)You want access to the @Deployment to manipulate it based on the TestClass ?
How about ApplicationArchiveProcessor?
-
2. Re: Dynamic deployments
bmajsak Oct 25, 2011 5:19 AM (in response to aslak)I was thinking about this one but wasn't certain if it's the right place to put dependencies which are used by the extension itself. I thought that the proper way is to append extension jar itself. But if it's the way to go then it's definitely easier! Thanks a lot!
-
3. Re: Dynamic deployments
aslak Oct 25, 2011 11:56 AM (in response to bmajsak)You should be able to @Inject Instance<TestClass> in the AuxilliaryArchiveAppender as well.
AuxilliaryArchiveAppender's are more for static stuff at this point. The problem with them is that you can't control which to include when. So e.g. even if a JSFUnit is not used in a specific test, it's still bundled.
-
4. Re: Dynamic deployments
bmajsak Oct 27, 2011 6:27 PM (in response to aslak)In 1.0.0.CR5 I'm not able to @Inject Instance<TestClass> in the AuxilliaryArchiveAppender...
It always results with null. And I guess I cannot really use ApplicationArchiveProcessor to resolve dynamically which dependencies are needed hence they are actually used by the extension itself, not test.jar.
Does it mean that the only option is to bundle everything in AuxilliaryArchiveAppender?
-
5. Re: Dynamic deployments
aslak Oct 27, 2011 7:22 PM (in response to bmajsak)1 of 1 people found this helpfulaa, sorry. You can in master. I thought it was fixed earlier.
-
6. Re: Dynamic deployments
bmajsak Oct 28, 2011 1:52 AM (in response to bmajsak)Thanks a lot! It works with 1.0.0.Final-SNAPSHOT
-
7. Re: Dynamic deployments
bmajsak Dec 12, 2011 7:12 AM (in response to bmajsak)Didn't really feel like it should be part of seperated thread so I decided to extend already existing one
My problem now is - I moved logic to include datasets from extension jar itself to the test archive using ApplicationArchiveProcessor (as suggested). However this approach forces me to deal with different types of archive. My use case is - I want to add dataset files to root datasets folder (or any other defined by user). It works for JARs obviously, but for instance in case of WAR I need to put them under WEB-INF, and so on.
So I was wondering if there is a way to include additional JAR with all dependencies I need (datasets in particular, but maybe also libraries dynamically determined), let's say arquillian-persistence-extension-deps.jar. I extended AnnotationDeploymentScenarioGenerator and created additional DeploymentDescriptor, but it's not visible for extension jar. Is there any way to put it on extension's classpath? Or maybe some other solution for my problem exists?
-
8. Re: Dynamic deployments
aslak Dec 12, 2011 7:52 AM (in response to bmajsak)I think you should comply to the ResourceContainer interface, and in the case of ResourceContainer not being supported by the Archive(ear), you should pack your resources as a JavaArchive and comply with the LibraryContainer interface. ShrinkWrap should handle the underlying locations in the target Archive..
or optinally the other way around, comply to LibraryContainer where supported, but if unsupported(jar) use as a ResourceContainer.
-
9. Re: Dynamic deployments
bmajsak Dec 12, 2011 7:55 AM (in response to aslak)And still appending to test archive, right?
-
10. Re: Dynamic deployments
aslak Dec 12, 2011 8:00 AM (in response to bmajsak)yes, but instead of checking if this is a WebArchive or a JavaArchive, see if the Archive support ResourceContianer or LibraryContianer
-
11. Re: Dynamic deployments
bmajsak Dec 12, 2011 8:03 AM (in response to aslak)That's clear. Thx a lot!
Is there any way to get rid off the AuxilliaryArchiveAppender's static nature in the next major release? I have a feeling that those dependencies would be more happy sitting within extension jar instead of test archive
-
12. Re: Dynamic deployments
aslak Dec 12, 2011 8:06 AM (in response to bmajsak)Yeah, we need to rethink some of the packaging pipeline to make it more extension friendly. It a bit all or nothing atm.