You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rodney Waldhoff <rw...@apache.org> on 2003/10/27 17:11:35 UTC
[collections] ant target "validate-build-testframework" fails?
Using the cvs HEAD of commons-collections, I get a build failure when
running:
ant clean dist
because of a failue in the target "validate-build-testframework", due to
the org.apache.commons.collections.BidiMap class not being available in
the classpath used in the javac task initiated on line 298 of build.xml
("cannot resolve symbol" for "class BidiMap" in 17 places in
AbstractTestBidiMap.java)
Based on the comment in build.xml, it seems this target is trying to
confirm that the testframework can be built without the rest of
commons-collections. Given AbstractTestBidiMap, this is no longer the
case. I'm not sure what the intention is here.
If we want to assert that the testframework is independent of the
"production" classes, then we'll have to change AbstractTestBidiMap to not
rely upon the BidiMap type, or remove it altogether, or remove that class
from the testframework JAR. If this is the intention, we should tweak the
build order to make this constraint explicit, rather than relying upon an
additional ant task to confirm it.
If we want to simply relax that constraint, and allow testframework to
depend upon the "production" classes, then I suppose we can drop the
validate-build-testframework package altogether.
Thoughts?
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] ant target "validate-build-testframework" fails?
Posted by Rodney Waldhoff <rw...@apache.org>.
Assuming the second option is what we'll eventually do, I've temporarily
disabled the validate-build-testframework target by commenting out it's
body (and adding an <echo> to that effect). If you actually want to see
this target fail, you'll need to uncomment that body.
On Mon, 27 Oct 2003, Rodney Waldhoff wrote:
> Using the cvs HEAD of commons-collections, I get a build failure when
> running:
>
> ant clean dist
>
> because of a failue in the target "validate-build-testframework", due to
> the org.apache.commons.collections.BidiMap class not being available in
> the classpath used in the javac task initiated on line 298 of build.xml
> ("cannot resolve symbol" for "class BidiMap" in 17 places in
> AbstractTestBidiMap.java)
>
> Based on the comment in build.xml, it seems this target is trying to
> confirm that the testframework can be built without the rest of
> commons-collections. Given AbstractTestBidiMap, this is no longer the
> case. I'm not sure what the intention is here.
>
> If we want to assert that the testframework is independent of the
> "production" classes, then we'll have to change AbstractTestBidiMap to not
> rely upon the BidiMap type, or remove it altogether, or remove that class
> from the testframework JAR. If this is the intention, we should tweak the
> build order to make this constraint explicit, rather than relying upon an
> additional ant task to confirm it.
>
> If we want to simply relax that constraint, and allow testframework to
> depend upon the "production" classes, then I suppose we can drop the
> validate-build-testframework package altogether.
>
> Thoughts?
>
> - Rod <http://radio.weblogs.com/0122027/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] ant target "validate-build-testframework" fails?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
The top of the build xml has a section that describes the files necessary
for the test framework.
<!-- patternset describing test framework source -->
<patternset id="patternset-testframework-source">
<include name="**/Bag.java"/>
<include name="**/SortedBag.java"/>
<include name="**/AbstractTest*.java"/>
<include name="**/BulkTest*.java"/>
</patternset>
The BidiMap should be added to this to solve this problem, my mistake.
Stephen
----- Original Message -----
From: "Rodney Waldhoff" <rw...@apache.org>
> Using the cvs HEAD of commons-collections, I get a build failure when
> running:
>
> ant clean dist
>
> because of a failue in the target "validate-build-testframework", due to
> the org.apache.commons.collections.BidiMap class not being available in
> the classpath used in the javac task initiated on line 298 of build.xml
> ("cannot resolve symbol" for "class BidiMap" in 17 places in
> AbstractTestBidiMap.java)
>
> Based on the comment in build.xml, it seems this target is trying to
> confirm that the testframework can be built without the rest of
> commons-collections. Given AbstractTestBidiMap, this is no longer the
> case. I'm not sure what the intention is here.
>
> If we want to assert that the testframework is independent of the
> "production" classes, then we'll have to change AbstractTestBidiMap to not
> rely upon the BidiMap type, or remove it altogether, or remove that class
> from the testframework JAR. If this is the intention, we should tweak the
> build order to make this constraint explicit, rather than relying upon an
> additional ant task to confirm it.
>
> If we want to simply relax that constraint, and allow testframework to
> depend upon the "production" classes, then I suppose we can drop the
> validate-build-testframework package altogether.
>
> Thoughts?
>
> - Rod <http://radio.weblogs.com/0122027/>
>
> ---------------------------------------------------------------------
> 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