-
1. Re: Shrinkwrap usage in Arquillian tests
bosschaert Sep 6, 2010 6:18 AM (in response to thomas.diesler)Thomas Diesler wrote:
I don't fully understand why a bundle (a test bundle) can't create another bundle and install that. Whether this runs in a remote container or not.
So here's how this is done in the BundleSmokeTestCase. This test is in itself a bundle, which is installed in the remote container. When executed, it creates a potentially large number (the exact amount is parameterized) of bundles and installs these. The classes inside the dynamically generated bundles are bundled up as part of the bundle that contains the BundleSmokeTestCase so available to Shrinkwrap from there (never from the System classpath).
This test uses Shrinkwrap purely as a utility. It could also use plain Java calls to create the archive, but with Shrinkwrap it's obviously a lot easier. Whether Shrinkwrap is part of the arq bundle, or a separate bundle is a matter of taste IMHO...
The problem with the annotation approach is that for the BundleSmokeTestCase (and it's performance related variations) it's not flexible enough, as you want to be able to parameterize the test to run with hundreds, potentially thousands of bundles. Currently that's just a number passed in. That doesn't work if every bundle requires a separate annotation.
-
2. Re: Shrinkwrap usage in Arquillian tests
thomas.diesler Sep 6, 2010 6:47 AM (in response to bosschaert)You are saying that the test archive (i.e. the one generated by @Deployment) must contain the superset of all assets that are used by shrinkwrap from within test methods.
If the test archive exports/imports packages put into a shrinkwrap generated bundle, you have two bundles exporting the same package.
If the test archive does not export/import packages put into a shrinkwrap generated bundle. You have two class loaders for the same package and the test archive cannot integrate with the shrinkwrap generated bundle.
I claim that all test bundles must be generated on the client side with shrinkwrap loading assets from the test client's classpath.
A requirement we often have is that a given package is contained in a single bundle only. How can an ARQ test bundle generate such a bundle?
-
3. Re: Shrinkwrap usage in Arquillian tests
bosschaert Sep 6, 2010 7:04 AM (in response to thomas.diesler)Thomas Diesler wrote:
You are saying that the test archive (i.e. the one generated by @Deployment) must contain the superset of all assets that are used by shrinkwrap from within test methods.
correct, that's how I used it
If the test archive exports/imports packages put into a shrinkwrap generated bundle, you have two bundles exporting the same package.
If the test archive does not export/import packages put into a shrinkwrap generated bundle. You have two class loaders for the same package and the test archive cannot integrate with the shrinkwrap generated bundle.
in my case the test bundle doesn't export the package of the classes used by the generated bundles. Integration with the test bundles wasn't an issue for me as I just used JRE provided types for that, but if you want to use your own types that should still not be an issue as long as interfaces are used that are available in a shared bundle.
I claim that all test bundles must be generated on the client side with shrinkwrap loading assets from the test client's classpath.
A requirement we often have is that a given package is contained in a single bundle only. How can an ARQ test bundle generate such a bundle?
If it's is an absolute requirement that only 1 bundle contains a given package, you could store the class files you need in your dynamic bundles as resources in some resource directory in your test bundle so that the classloader will never see them as classfiles.
Bottom line for me is that I don't have a strong preference how this is done, as long as it's possible to do...
-
4. Re: Shrinkwrap usage in Arquillian tests
thomas.diesler Sep 6, 2010 8:20 AM (in response to bosschaert)As the outcome of this discussion I'd like to see a design proposal for dynamically generated test bundles that generally works for both the embedded and remote scenario. Remote OSGi testing is important for our AS7 integration goals. Lets discuss this further in one of our next calls.