too many classes visible with "ant javadocs"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

too many classes visible with "ant javadocs"

Daniel Naber
Hi,

the java API documentation now seems to contain classes which have no
useful documentation and thus probably shouldn't be part of the API docs,
e.g. Among, Testapp, SnowballProgram (maybe more).

Also, build.xml has a typo: "MorLikeThis" (Mor instead of More), but I
don't know whether this has any effect.

Regards
 Daniel

--
http://www.danielnaber.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: too many classes visible with "ant javadocs"

Erik Hatcher
On Apr 26, 2005, at 6:10 PM, Daniel Naber wrote:

> Hi,
>
> the java API documentation now seems to contain classes which have no
> useful documentation and thus probably shouldn't be part of the API
> docs,
> e.g. Among, Testapp, SnowballProgram (maybe more).
>
> Also, build.xml has a typo: "MorLikeThis" (Mor instead of More), but I
> don't know whether this has any effect.

Sorry for the typo.  This is still a work-in-progress - I only have a
little bit of time to devote to this per day and have checked in my
changes even though its not entirely complete.  By all means feel free
to take over the build process refactorings if you'd like.  I'm a bad
estimator of my time and had hoped to have the packaging changes for a
1.9 release finished but they aren't yet.  I'll keep plodding along,
but won't be upset if someone else jumps in.

        Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: too many classes visible with "ant javadocs"

Erik Hatcher
In reply to this post by Daniel Naber

On Apr 26, 2005, at 6:10 PM, Daniel Naber wrote:
> the java API documentation now seems to contain classes which have no
> useful documentation and thus probably shouldn't be part of the API
> docs,
> e.g. Among, Testapp, SnowballProgram (maybe more).

This is now fixed.  I excluded net.sf.* from being javadoc'd.  This
causes a warning when generating documentation for
SnowballAnalyzer/Filter, but its not a problem.

> Also, build.xml has a typo: "MorLikeThis" (Mor instead of More), but I
> don't know whether this has any effect.

Corrected, as well as made several adjustments to group packages
properly.  It took me a few tries to understand how the <group>
patterns work.

        Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: too many classes visible with "ant javadocs"

Daniel Naber-2
In reply to this post by Erik Hatcher
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: too many classes visible with "ant javadocs"

Erik Hatcher

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: too many classes visible with "ant javadocs"

Brian Goetz
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: too many classes visible with "ant javadocs"

Erik Hatcher
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: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...