You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Daniel Naber <da...@t-online.de> on 2005/05/01 21:06:59 UTC
Re: too many classes visible with "ant javadocs"
On Wednesday 27 April 2005 02:53, Erik Hatcher wrote:
> By all means feel free
> to take over the build process refactorings if you'd like.
I think you as the ant expert can do that much better, and my mail wasn't
meant as a complaint that things don't progress fast enough.
One small thing: "ant test" complains that JUnit isn't found if it's not in
classpath. As we have junit.jar in CVS, couldn't that be used
automatically?
Regards
Daniel
--
http://www.danielnaber.de
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: too many classes visible with "ant javadocs"
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On May 1, 2005, at 9:32 PM, Brian Goetz wrote:
>> junit.jar really ought to be removed from our repository. Due to
>> classloader issues, <junit> doesn't work with junit.jar anywhere but
>> in
>> the classpath that launches Ant. The Ant best practice is to put
>> junit.jar in ANT_HOME/lib anyway. I have adjusted the build file that
>> I'll check in later to account for this.
>
> I disagree that this is a "best practice." At best, it is a horrible
> workaround for two tools that ought to work better together, but don't,
> for reasons that no one has been able to explain compellingly.
By "best", I meant its the best alternative to dealing with it.
I haven't spent any time fiddling with the gory details of the
classloader issue. The <junit> task is the highest profile one, but
other tasks that require 3rd libraries suffer the same issue like <scp>
and <ftd> for example.
The explanations have been made on the Ant e-mail lists - I'd have to
dig to find the most technically detailed one and don't have it readily
at hand.
> What if you have different projects which use the same version of ANT
> but use different versions of JUnit? You're screwed.
That is a very unlikely occurrence. JUnit 3.8.1 has been the only
necessary version for a long time. And you wouldn't be screwed, you'd
just pull junit.jar out of ANT_HOME/lib but ensure that the one you
wanted was in the classpath for each project's build... via
build.bat/.sh scripts instead of using Ant's built-in launcher scripts
directly.
> What we've taken to doing is to "neuter" ANT by removing optional.jar,
> and add optional.jar to the lib/ directory of every project, along with
> junit. While this is not really a great practice either, it does
> provide more flexibility.
optional.jar? What version of Ant are you running?! That's pre-v1.6.
optional.jar was split into separate JAR files for each 3rd party
dependency.
All because of junit.jar you do that? Why can't all your projects use
the same junit.jar?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: too many classes visible with "ant javadocs"
Posted by Brian Goetz <br...@quiotix.com>.
> junit.jar really ought to be removed from our repository. Due to
> classloader issues, <junit> doesn't work with junit.jar anywhere but in
> the classpath that launches Ant. The Ant best practice is to put
> junit.jar in ANT_HOME/lib anyway. I have adjusted the build file that
> I'll check in later to account for this.
I disagree that this is a "best practice." At best, it is a horrible
workaround for two tools that ought to work better together, but don't,
for reasons that no one has been able to explain compellingly.
What if you have different projects which use the same version of ANT
but use different versions of JUnit? You're screwed.
What we've taken to doing is to "neuter" ANT by removing optional.jar,
and add optional.jar to the lib/ directory of every project, along with
junit. While this is not really a great practice either, it does
provide more flexibility.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: too many classes visible with "ant javadocs"
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On May 1, 2005, at 3:06 PM, Daniel Naber wrote:
> On Wednesday 27 April 2005 02:53, Erik Hatcher wrote:
>
>> By all means feel free
>> to take over the build process refactorings if you'd like.
>
> I think you as the ant expert can do that much better, and my mail
> wasn't
> meant as a complaint that things don't progress fast enough.
I've spent some time today refactoring the build process to unify the
main build to also build the contrib libraries, yet still allowing them
to be built by themselves. I will check in my effort later tonight.
> One small thing: "ant test" complains that JUnit isn't found if it's
> not in
> classpath. As we have junit.jar in CVS, couldn't that be used
> automatically?
junit.jar really ought to be removed from our repository. Due to
classloader issues, <junit> doesn't work with junit.jar anywhere but in
the classpath that launches Ant. The Ant best practice is to put
junit.jar in ANT_HOME/lib anyway. I have adjusted the build file that
I'll check in later to account for this.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org