[resources] An interesting problem
I am refactoring and removing the source files that directly link to code that falls outside of the ASL. I am moving these over to sf.net/struts and I am almost done, but for 1 small problem. If you've looked over any of the test cases, you know that the tests are actually conducted with calls tracing up the hierarchy to ResourcesFactoryBaseTestCase. I want my test classes to reuse this same test code, but I don't know what the best approach is. I don't want to copy/paste the existing code because I don't care to maintain the same code in 2 places. However, I can't simply reference the jar.because there is no jar, they are just test classes. What would you do? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] An interesting problem
James Mitchell wrote: I want my test classes to reuse this same test code, but I don't know what the best approach is. I don't want to copy/paste the existing code because I don't care to maintain the same code in 2 places. However, I can't simply reference the jar.because there is no jar, they are just test classes. What would you do? Create a jar containing the test classes. If other projects depend on these tests, then they are a valid artifact produced by the project and no longer just test classes. I run into this situation frequently when I have one component which defines a set of interfaces, and also tests for these interfaces. Then, I have another component which implements the interfaces, and the tests need to reference the interface tests. So, I'm in the habit of producing test jars along side the normal ones. [collections] does something similar to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] An interesting problem
Currently the project.xml produces commons-resources-1.0-dev.jar Can you help me with how I need to tell maven to create a 2nd artifact? Something like commons-resources-tests-1.0-dev.jar -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: matthew.hawthorne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Friday, August 27, 2004 4:12 PM Subject: Re: [resources] An interesting problem James Mitchell wrote: I want my test classes to reuse this same test code, but I don't know what the best approach is. I don't want to copy/paste the existing code because I don't care to maintain the same code in 2 places. However, I can't simply reference the jar.because there is no jar, they are just test classes. What would you do? Create a jar containing the test classes. If other projects depend on these tests, then they are a valid artifact produced by the project and no longer just test classes. I run into this situation frequently when I have one component which defines a set of interfaces, and also tests for these interfaces. Then, I have another component which implements the interfaces, and the tests need to reference the interface tests. So, I'm in the habit of producing test jars along side the normal ones. [collections] does something similar to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] An interesting problem
James Mitchell wrote:
Currently the project.xml produces commons-resources-1.0-dev.jar
Can you help me with how I need to tell maven to create a 2nd artifact?
Something like commons-resources-tests-1.0-dev.jar
The cleanest way is to split the project into 2 subprojects.
commons-resources/
core/
src/
main/
tests/
src/
main/
Make the 2nd project depend on the 1st. You could do maven
multiproject:install
in the commons-resources directory to build them both.
However, a lot of people find this undesirable. You could do some maven.xml
magic to make this happen instead, and keep everything in one source tree.
Here's an example of how I did this, before I switched to the
multiproject format.
!-- Builds and deploys test jar --
postGoal name=jar:jar
ant:jar destfile=${maven.build.dir}/${testjar.name}
fileset dir=${maven.build.dir}/test-classes/
/ant:jar
/postGoal
define the property 'testjar.name' as whatever you want.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
