[#PAXEXAM-157] Include necessary Jars in the testbundle

Pax Exam

Include necessary Jars in the testbundle

Created: 17/Nov/09 10:53 AM Updated: 22/Jan/10 12:13 PM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

2.0.0

Description

« Hide

Sometimes you want to use some external libraries in your testmethod that are in separate jars. These libraries aren't automatically included in the testbundle Pax Exam generates and when accessing the classes in the testmethod, a NoClassDefFoundError is thrown.

All

Comments

Change History

FishEye

Crucible

Builds

Sort Order:

[ Permlink | « Hide ]

Toni Menzel added a comment - 17/Nov/09 11:07 AM

As explained by Walter in a chat, this is particularly useful when you do not influence your system by bundles + packages that just exist in your test setup but not in the live system.
The current way is to just add that library as a wrapped bundle to your provisioning stack.

[ Permlink | « Hide ]

Walter Treur added a comment - 19/Nov/09 05:44 PM

I'm currently working to modify my local version if Exam to implement this behavior.

I created a new CoreOption that can be used in the JUnit @Configuration method

@Configuration
public static Option[] configuration() throws Exception { dependencyOption("/some/jar/folder", "the.jar"), }

It uses the assembly protocol instead of the Pax URL dir protocol to create the testbundle and include the jar. It also puts the jar in the Bundle-Classpath.
This works pretty well, except that I want to extend this to allow multiple jars to be set (thats why U haven't committed it yet)
I think however it should be generalized to some API to make full use of the possibilities of the Pax URL assembleRef protocol (http://wiki.ops4j.org/pages/viewpage.action?pageId=12648754#%22assembly%22protocol-assemblyref) Or else, instead of an API, you could specify the location of JSON file.

With the 'JSON file'-solution you should manually specify the class file of your test in that file (or else your testclass isn't available in the testbundle). That is a lot of boilerplate if you ask me. So one can think of a solution where your custom JSON is extended with the location of your testclass (and optional subclasses since they are compiled to separate class files) With that, I ran in another problem with the current use of Pax URL dir protocol.

At this moment. The root dir of your testclass is used by Pax URL-dir to locate your testclass (and dependencies) But what if your junit test-class is located (eg) in a jar? That won't work either.

With the problem of external dependencies and locating the testclass itself I think we should consider an (substantial) modification of the generation of the testbundle. Toni mentioned in a chat to me that the Pax URL dir is a little rough. I agree. Classes that aren't necessarily used are included in the test, because the are located in the (subfolder) of the testclass root folder.

I'm not sure how trhe testbundle should be generated, but I think it should include solutions for the problems described above. Perhaps something with specifying a custom classpath and that all the classes and jars on this classpath are automatically included in the testbundle. But what if you want use testclasses located in a maven repository? I think the assembly protocol is most suitable. But in what form should it be implemented?

[ Show » ]

Walter Treur added a comment - 19/Nov/09 05:44 PM I'm currently working to modify my local version if Exam to implement this behavior. I created a new CoreOption that can be used in the JUnit @Configuration method @Configuration public static Option[] configuration() throws Exception { dependencyOption("/some/jar/folder", "the.jar"), } It uses the assembly protocol instead of the Pax URL dir protocol to create the testbundle and include the jar. It also puts the jar in the Bundle-Classpath. This works pretty well, except that I want to extend this to allow multiple jars to be set (thats why U haven't committed it yet) I think however it should be generalized to some API to make full use of the possibilities of the Pax URL assembleRef protocol (http://wiki.ops4j.org/pages/viewpage.action?pageId=12648754#%22assembly%22protocol-assemblyref) Or else, instead of an API, you could specify the location of JSON file. With the 'JSON file'-solution you should manually specify the class file of your test in that file (or else your testclass isn't available in the testbundle). That is a lot of boilerplate if you ask me. So one can think of a solution where your custom JSON is extended with the location of your testclass (and optional subclasses since they are compiled to separate class files) With that, I ran in another problem with the current use of Pax URL dir protocol. At this moment. The root dir of your testclass is used by Pax URL-dir to locate your testclass (and dependencies) But what if your junit test-class is located (eg) in a jar? That won't work either. With the problem of external dependencies and locating the testclass itself I think we should consider an (substantial) modification of the generation of the testbundle. Toni mentioned in a chat to me that the Pax URL dir is a little rough. I agree. Classes that aren't necessarily used are included in the test, because the are located in the (subfolder) of the testclass root folder. I'm not sure how trhe testbundle should be generated, but I think it should include solutions for the problems described above. Perhaps something with specifying a custom classpath and that all the classes and jars on this classpath are automatically included in the testbundle. But what if you want use testclasses located in a maven repository? I think the assembly protocol is most suitable. But in what form should it be implemented?

[ Permlink | « Hide ]

Walter Treur added a comment - 22/Jan/10 12:13 PM

The issue described is addressed with TinyBundles. (http://wiki.ops4j.org/display/paxexam/ExamAndTinybundles)

I'm closing this issue since using TinyBundle doesn't require any changes to the automatic testbundle generation of Exam.