commons-dev mailing list archives

Looking further into it, Jeff, I find in
http://jakarta.apache.org/turbine/maven/reference/user-guide.html#POM%20Processing
that
The properties files in Maven are processed in the following order:
${maven.home}/bin/driver.properties
${project.home}/project.properties
${project.home}/build.properties
${user.home}/build.properties
Perhaps you have something defined in one of these places that allows the tests to pull the
needed jars when they are run?
I tried playing with the maven.junit.fork property, but running maven ant over a properties
file that defined this property to false did not cause the build.xml to change.
Is there something else I must do to explicitly plug the plugin in?
-----Original Message-----
From: Steve Cohen
Sent: Sat 3/1/2003 9:57 PM
To: Jakarta Commons Developers List; Jakarta Commons Developers List
Cc:
Subject: RE: [NET] Re: dependency dilemma
Jeff - I hadn't known that I wasn't supposed to touch build.xml directly. I didn't know maven
could generate it for me. That's a cool feature. Simply adding oro to the dependency list
as you indicated does get it into the build file and allows the project to build.
However, the xml-parsing jars are NOT in the classpath when the test goal is run and the test
target fails. I can get it to succeed either by manually changing the build.xml to run the
test target with fork false, or by adding xml-apis.jar and xercesImpl.jar to the get-deps
list. But out of the box, it fails.
So something is wrong. The tests won't run without these jars and there's nothing in the
build.xml file as created by maven that puts them there. (These jars are not needed to compile
the tests, only to run them). So I would assume that there are some maven configuration options
we need to change to do to get them there.
I will take a look at the maven docs that deal with genning the build.xml and see if I can
find an answer.
Steve
-----Original Message-----
From: Jeffrey D. Brekke [mailto:jbrekke@wi.rr.com]
Sent: Sat 3/1/2003 7:01 PM
To: Jakarta Commons Developers List
Cc:
Subject: Re: [NET] Re: dependency dilemma
Steve I never had these issues when the ftp2 code was in the source tree.
The xml-parsing jars should be present when the test goal is run, we never had that
dependency in the POM.
Also you shouldn't be modifying the ant build file by hand, but
instead generate a new one with maven:
maven ant
This would then reflect the change in dependecies from the POM. Does
the build work properly with maven and your just having troubles with
the ant build?
Does this help?
jb
"Steve Cohen" <SCohen@sportvision.com> writes:
> That was easy enough.
>
> I added the ORO dependency back in (and also an entry in the
> get-deps target to pull it in) and all those problems went away.
>
> However, I then found, that with moving the tests into src/test as I
> had planned to do, simply having junit brought in through maven
> doesn't fully solve the problem as we also have to bring in the
> xml-parsing jars as well. This is a run-test-time problem that
> doesn't appear until you actually have tests to run.
>
> Two solutions here 1) make the fork attribute of the junit task-call
> in the internal-test target false and get the benefit of the
> xml-parsing jars that are already used in ant. I'm not sure what
> bad side-effects this will have 2) drag these jars over to our side,
> using the get-deps target (or perhaps a new get-test-deps target).
>
> I'm not sure what the preferred maven way is here.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org