You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Ernst de Haan <er...@jollem.com> on 2000/07/08 00:46:21 UTC
Javadoc task: author and version should be unset by default
Hi,
I am currently developing an open-source JavaDoc check tool, called
DocLint. I use Ant both for building DocLint, and for checking the
JavaDoc comments of other projects. I implemented DocLint as a doclet,
so for the checking I used the `javadoc' task and set the `doclet' and
`docletpath' properties.
But what I found out when I tried to let Ant do the checking, that the
`version' and `author' properties are set to `yes' by default. But these
properties are only valid for the standard doclet, not for doclets in
general. So IMHO these properties should be unset.
I have attached a diff file (the result of cvs diff).
Ernst
RE: WebLogic 4.x EJB Tasks
Posted by Ken Liu <kl...@auctionlogic.com>.
Conor,
I just got around to trying out the DDCreator and ejbc tasks. I'm following
up here on a post from last week:
My questions:
1) Did anyone ever come up with a patch to EjbcHelper to allow the
"-compiler jikes" to be passed in? I may do this if it hasn't already been
done. It's great to be able to skip the ejbc, but ejbc is really really
slow without jikes.
2) I am using TOPLink for Weblogic, which requires that the System variables
"weblogic.home" and "weblogic.system.home" be set in the JVM for the
DDCreator. When you install TOPLink it installs some jar file into
/weblogic/lib which DDCreator then finds using those System variables. This
is only for TOPLink beans of course. So my current DDCreator task looks
something like this:
<java classname="${ejb.ddcreator}" fork="yes"
jvmargs="-Dweblogic.home=${lib.weblogic.dir} -Dweblogic.system.home=${lib.we
blogic.dir} -cp ${classpath}" args="-dir /build/classes/[path to
bean] -outputfile SomeEjbDD.ser ${src.dir}/[path to bean]SomeEjbDD.txt"/>
So my question is: Can I pass the jvmargs to the <ddcreator> task?
Ken
> -----Original Message-----
> From: Conor MacNeill [mailto:conor@cognet.com.au]
> Sent: Monday, July 10, 2000 6:47 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: WebLogic 4.x EJB Tasks
>
>
> Paul,
>
> > From: Paul Hodgetts [mailto:paulh@zzyzxtek.com]
> >
> > I've been using the new WebLogic 4.x EJB tasks and I have a few
> > comments/questions. These tasks are very cool and help us out a
> > whole lot with our builds. Thank you!
>
> Thanks for the feedback.
>
> >
> > DDCreator works great. No issues there.
> >
> > Ejbc works well, with the following comments/questions:
> >
> > 1. There are some command line parameters that are not passed in.
> > For example, -g -nowarn -debug can't be set. -keepgenerated is
> > hard coded as always on. I was playing around in EjbcHelper by
> > just putting them on the command line, and they seem to work
> > fine. It looks pretty straightforward to pass them through (if
> > I understand the design).
>
> I developed these tasks initially to serve the EJB builds we are doing at
> Cortex without much regard for supporting all options. It
> shouldn't be hard
> to add those options. The whole split between ejbc and ejbcHelper was done
> for classpath reasons and I just put the things I needed into the
> interface.
>
> I am happy if you want to make changes and submit patches.
>
> >
> > 2. I was trying to add -compiler jikes to the EjbcHelper command
> > line, and it didn't work. It seemed to generate the first bean
> > that it came across, but didn't continue on to any more. I
> > think it may have something to do with how it's invoked, but I
> > don't understand it enough to know why and how to fix it. The
> > reason I want to use Jikes is because Jikes is twice as fast as
> > the JDK compiler. We have a lot of beans to generate, and it
> > cuts 5 minutes off a full build.
>
> I haven't tried to use Jikes with ejbc. I have heard from someone who has
> done it. They added
RE: WebLogic 4.x EJB Tasks
Posted by Conor MacNeill <co...@cognet.com.au>.
Paul,
> From: Paul Hodgetts [mailto:paulh@zzyzxtek.com]
>
> I've been using the new WebLogic 4.x EJB tasks and I have a few
> comments/questions. These tasks are very cool and help us out a
> whole lot with our builds. Thank you!
Thanks for the feedback.
>
> DDCreator works great. No issues there.
>
> Ejbc works well, with the following comments/questions:
>
> 1. There are some command line parameters that are not passed in.
> For example, -g -nowarn -debug can't be set. -keepgenerated is
> hard coded as always on. I was playing around in EjbcHelper by
> just putting them on the command line, and they seem to work
> fine. It looks pretty straightforward to pass them through (if
> I understand the design).
I developed these tasks initially to serve the EJB builds we are doing at
Cortex without much regard for supporting all options. It shouldn't be hard
to add those options. The whole split between ejbc and ejbcHelper was done
for classpath reasons and I just put the things I needed into the interface.
I am happy if you want to make changes and submit patches.
>
> 2. I was trying to add -compiler jikes to the EjbcHelper command
> line, and it didn't work. It seemed to generate the first bean
> that it came across, but didn't continue on to any more. I
> think it may have something to do with how it's invoked, but I
> don't understand it enough to know why and how to fix it. The
> reason I want to use Jikes is because Jikes is twice as fast as
> the JDK compiler. We have a lot of beans to generate, and it
> cuts 5 minutes off a full build.
I haven't tried to use Jikes with ejbc. I have heard from someone who has
done it. They added
-compiler jikes
and
-classpath blah
If that works we would need to pass the classpath across the interface too.
>
> 3. The task uses the -noexit parameter. I don't see this
> documented anywhere in the WebLogic docs. Is this a secret
> parameter? I would guess it allows the VM to stay open, but
> I've never seen it mentioned in the WebLogic stuff before.
>
OK, I saw it had been added to ddcreator and guessed it was also done for
ejbc. It worked. While I was reluctant to use an undocumented feature, I
think the ability to run multiple ejbcs in one VM was a performance gain.
The downside to the -noexit tag is that when it is used and there is a
problem ejbc swallows the exception that caused the error and throws a
simple exception to terminate. If you look at the code you will see that
when I catch an exception I rerun the last ejbc call without the -noexit
flag to get it to give me the real exception. It is a big ugly but it works.
> 4. I'm not sure how the connection is made (if it is) between the
> bean sources and the generated classes. For example, if I have
> the user written MyClassBean.java, MyClassHome.java, etc., how
> does the Ejbc task know to regen if any of the user sources have
> changed? My suspicion is that this is difficult/impossible in a
> generic way (without some naming conventions), so maybe I just
> have to code up something custom for our situation.
>
EjbcHelper reads in the serialised deployment descriptor to discover the
interface names and class names including the bean class name. The generated
code class names is derived from the beanclass name. The derivation is
indeed based on the naming conventions used by Weblogic. Once I have all the
class names I can determine the source file names and check what things are
out of date. It is not truly generic but it does seem reasonably reliable.
Being able to avoid ejbc compiles cuts down build time in a major way.
> 5. It seems like the Ejbc task using javac is noticeably slower
> than when I was using the java task to fire it off (even with
> javac as the compiler both ways). Is it invoking ejbc in a
> different way or am I just hallucinating? ;-)
I think you are hallucinating :-). Seriously I can't think why it would be
slower. If you find something, let us know.
>
> Any insights into my questions would be appreciated. As to the
> changes that I know how to do, what should I do next? Do I make the
> changes and submit them to someone, or wait for someone else to make
> them, or what? I'm new to this, so I'm not sure how to proceed.
>
Have a read of http://jakarta.apache.org/guidelines/source.html
It discusses how to submit patches. Then just jump in :-)
Conor
WebLogic 4.x EJB Tasks
Posted by Paul Hodgetts <pa...@zzyzxtek.com>.
I've been using the new WebLogic 4.x EJB tasks and I have a few
comments/questions. These tasks are very cool and help us out a
whole lot with our builds. Thank you!
DDCreator works great. No issues there.
Ejbc works well, with the following comments/questions:
1. There are some command line parameters that are not passed in.
For example, -g -nowarn -debug can't be set. -keepgenerated is
hard coded as always on. I was playing around in EjbcHelper by
just putting them on the command line, and they seem to work
fine. It looks pretty straightforward to pass them through (if
I understand the design).
2. I was trying to add -compiler jikes to the EjbcHelper command
line, and it didn't work. It seemed to generate the first bean
that it came across, but didn't continue on to any more. I
think it may have something to do with how it's invoked, but I
don't understand it enough to know why and how to fix it. The
reason I want to use Jikes is because Jikes is twice as fast as
the JDK compiler. We have a lot of beans to generate, and it
cuts 5 minutes off a full build.
3. The task uses the -noexit parameter. I don't see this
documented anywhere in the WebLogic docs. Is this a secret
parameter? I would guess it allows the VM to stay open, but
I've never seen it mentioned in the WebLogic stuff before.
4. I'm not sure how the connection is made (if it is) between the
bean sources and the generated classes. For example, if I have
the user written MyClassBean.java, MyClassHome.java, etc., how
does the Ejbc task know to regen if any of the user sources have
changed? My suspicion is that this is difficult/impossible in a
generic way (without some naming conventions), so maybe I just
have to code up something custom for our situation.
5. It seems like the Ejbc task using javac is noticeably slower
than when I was using the java task to fire it off (even with
javac as the compiler both ways). Is it invoking ejbc in a
different way or am I just hallucinating? ;-)
Any insights into my questions would be appreciated. As to the
changes that I know how to do, what should I do next? Do I make the
changes and submit them to someone, or wait for someone else to make
them, or what? I'm new to this, so I'm not sure how to proceed.
Thanks,
-Paul Hodgetts
RE: Recent logging aint emacs friendly
Posted by Peter Donald <do...@mad.scientist.com>.
At 09:35 8/7/00 -0700, you wrote:
>I feel a little funny jumping into this conversation, since I
>just started following this mail list last week and I'm not
>sure of the protocol of the list yet, but...
welcome :P
>Having a mode to the default logger means that you have to go
>in and modify the logger if you ever want to add more modes.
>The logger class is not closed from extensions in this way and
>may end up having a whole lot of cases for the different modes.
I used to think this way until I recently discovered that forward designing
is the bane of much of my code. I end up constantly refactoring when
classes use parts of classes every time I want to add a new logger. Which
essentially means lots more work than special cases and sometimes not for
very much benefit.
How many different types of logger is ant going to need that will derive
from default logger ? I can only really think of special cases that email
results for overnight testing + building or special listener for IDEs when
they include Ant. None of these cases will inherit from DefaultLogger so
there is little point in making it generic. The extent we would have to go
to to make it generic enough for inheritance is much larger than a simple
if statement based on a property. We can always factor it out later if it
becomes cluttered :P.
>Having separate logger classes means the default logger can be
>closed to modifications when new loggers are added. New modes
>just mean writing a new logger class. I'm assuming there's
>some sort of factory method/class that knows how to instantiate
>the logger based on the command line property.
yes but it needs to be reworked as you can't get at commandline parameters
from the logger. ie you can't get what current log level and no access to
any command line parameters
>If the command line syntax is not clean, that can be changed
>independent of the logger class by just updating the syntax and
>the factory method/class that reads the property to build the
>corresponding logger class.
yup
>BTW, Conor, I started using your DDCreator and ejbc tasks for
>WebLogic 4.x, and I have a couple of comments and questions.
>Should I email you off line or on the list?
email on list as there maybe someone elses imagination you may spark with
your comments. Not me but there may be someone :P.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
RE: Recent logging aint emacs friendly
Posted by Paul Hodgetts <pa...@zzyzxtek.com>.
I feel a little funny jumping into this conversation, since I
just started following this mail list last week and I'm not
sure of the protocol of the list yet, but...
Conor MacNeill wrote:
> With option2 you could use a different logger - something like
>
> ant -logger emacs.logger -listener foo.bar
>
> Option 1 is about changing the behaviour of the default logger. So something
> like
>
> ant -emacsMode -listener foo.bar
>
>
> Thoughts?
Having a mode to the default logger means that you have to go
in and modify the logger if you ever want to add more modes.
The logger class is not closed from extensions in this way and
may end up having a whole lot of cases for the different modes.
Having separate logger classes means the default logger can be
closed to modifications when new loggers are added. New modes
just mean writing a new logger class. I'm assuming there's
some sort of factory method/class that knows how to instantiate
the logger based on the command line property.
If the command line syntax is not clean, that can be changed
independent of the logger class by just updating the syntax and
the factory method/class that reads the property to build the
corresponding logger class.
So, I think option 2 provides the cleaner and more flexible
internal architecture.
Hopefully, I haven't jumped in where I'm not supposed to be,
and that I haven't misinterpreted the thread. I'm sure someone
will let me know if I did. ;-)
BTW, Conor, I started using your DDCreator and ejbc tasks for
WebLogic 4.x, and I have a couple of comments and questions.
Should I email you off line or on the list?
-Paul Hodgetts
RE: Recent logging aint emacs friendly
Posted by Conor MacNeill <co...@m64.com>.
> From: Ernst de Haan [mailto:ernst@jollem.com]
> Sent: Sunday, 9 July 2000 0:15
> To: ant-dev@jakarta.apache.org
> Subject: Re: Recent logging aint emacs friendly
>
>
> Hi Conor && all,
>
> <snip>
> > Option 1 boils downs to a single logger class which has two behaviours
> > controlled by the command line parameter.
> >
> > Option 2 is 2 logger classes with separate behaviours.
> </snip>
>
> I would prefer the first option, because:
>
> * I expect this to be `cleaner'
> * I believe it is realistic that different logging formats are
> requested in the future, like XML.
>
> We can start by refactoring the existing code to factor the logging
> stuff out and put it in a separate class. At the same time we can think
> about a generic interface or abstract superclass.
>
Ernst, this is already here and part of the benefit of the build events code
that Matt Foemmel contributed. Try
ant -listener org.apache.tools.ant.XmlLogger
You will have a log.xml file produced from your build. In the src/etc
directory there is a stylesheet that you can use with this XML file.
The way ant is currently working it adds a listener at startup which is the
default logger. The -listener option simply adds more listeners. Of course,
to be useable only one of the listeners can be writing to System.out.
Currently this is the DefaultLogger and it can't be changed.
With option2 you could use a different logger - something like
ant -logger emacs.logger -listener foo.bar
Option 1 is about changing the behaviour of the default logger. So something
like
ant -emacsMode -listener foo.bar
Thoughts?
Conor
Re: Recent logging aint emacs friendly
Posted by Ernst de Haan <er...@jollem.com>.
Hi Conor && all,
<snip>
> Option 1 boils downs to a single logger class which has two behaviours
> controlled by the command line parameter.
>
> Option 2 is 2 logger classes with separate behaviours.
</snip>
I would prefer the first option, because:
* I expect this to be `cleaner'
* I believe it is realistic that different logging formats are
requested in the future, like XML.
We can start by refactoring the existing code to factor the logging
stuff out and put it in a separate class. At the same time we can think
about a generic interface or abstract superclass.
Perhaps we can introduce one extra subclassing layer, so both the
emacs-friendly and the standard logger can derive from the same class
and only have to do very little to get the behaviour they require.
Ernst
RE: Recent logging aint emacs friendly
Posted by Conor MacNeill <co...@m64.com>.
> -----Original Message-----
> From: Ernst de Haan [mailto:ernst@jollem.com]
> Sent: Saturday, 8 July 2000 23:22
> To: ant-dev@jakarta.apache.org
> Subject: Re: Recent logging aint emacs friendly
>
>
> <snip>
> > > Hmm, perhaps the logger can be specified as a parameter for the root
> > > element in the build file.
> </snip>
> <snip>
> > I don't think this would be good. The logger to be used in a
> build is not
> > really a property of the project. A PI makes some sense but I
> still think
> > this should be specified outside the project file. Logging is
> something the
> > user running ant is worried about, not the author of the build file. My
> > preference would therefore be to use a command line parameter.
> </snip>
>
> Yup. You are right. It must be known before the build.xml is actually
> parsed, because the setting will influence the output from the start on.
> So I agree a command-line option would be the answer.
>
> <snip>
> > 1. add a parameter to ant which causes the default listener to
> produce emacs
> > friendly output.
> > 2. allow the logger class to be specified on the command line and then
> > provide an emacs friendly logger.
> > 3. combine 1 and 2.
> </snip>
>
> What exactly do you mean by the first option ?
>
Option 1 boils downs to a single logger class which has two behaviours
controlled by the command line parameter.
Option 2 is 2 logger classes with separate behaviours.
Conor
Re: Recent logging aint emacs friendly
Posted by Ernst de Haan <er...@jollem.com>.
<snip>
> > Hmm, perhaps the logger can be specified as a parameter for the root
> > element in the build file.
</snip>
<snip>
> I don't think this would be good. The logger to be used in a build is not
> really a property of the project. A PI makes some sense but I still think
> this should be specified outside the project file. Logging is something the
> user running ant is worried about, not the author of the build file. My
> preference would therefore be to use a command line parameter.
</snip>
Yup. You are right. It must be known before the build.xml is actually
parsed, because the setting will influence the output from the start on.
So I agree a command-line option would be the answer.
<snip>
> 1. add a parameter to ant which causes the default listener to produce emacs
> friendly output.
> 2. allow the logger class to be specified on the command line and then
> provide an emacs friendly logger.
> 3. combine 1 and 2.
</snip>
What exactly do you mean by the first option ?
Ernst
RE: Recent logging aint emacs friendly
Posted by Conor MacNeill <co...@m64.com>.
> From: Ernst de Haan [mailto:ernst@jollem.com]
> Sent: Saturday, 8 July 2000 20:55
> To: ant-dev@jakarta.apache.org
> Subject: Re: Recent logging aint emacs friendly
>
>
> Hmm, perhaps the logger can be specified as a parameter for the root
> element in the build file.
>
> Ernst
>
I don't think this would be good. The logger to be used in a build is not
really a property of the project. A PI makes some sense but I still think
this should be specified outside the project file. Logging is something the
user running ant is worried about, not the author of the build file. My
preference would therefore be to use a command line parameter.
I think the options would be
1. add a parameter to ant which causes the default listener to produce emacs
friendly output.
2. allow the logger class to be specified on the command line and then
provide an emacs friendly logger.
3. combine 1 and 2.
Thoughts?
Re: Recent logging aint emacs friendly
Posted by Ernst de Haan <er...@jollem.com>.
Hmm, perhaps the logger can be specified as a parameter for the root
element in the build file.
Ernst
Peter Donald wrote:
> Hi,
>
> Th recent loggin addition is not emacs friendly at all. Would it be
> possible to change the DefaultLogger so that it doesn't output " [task] "
> at front of log messages. Alternatively it could be made dependant on a
> property/PI ???
>
> I have also been thinking that a PI that sets the formatter maybe a good
> idea. Currently I run all my ant output through awk to rewrite "build/src/"
> to "src/main" again to make it emacs friendly. Because then when you click
> goto error it goes to error in original source rather than in src that has
> been copied into build sub-directory. Is it worth making this a seperate
> Logger ?
>
>
> Cheers,
>
> Pete
>
> *------------------------------------------------------*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power." |
> | -Abraham Lincoln |
> *------------------------------------------------------*
RE: Recent logging aint emacs friendly
Posted by Peter Donald <do...@mad.scientist.com>.
At 11:13 8/7/00 +1000, you wrote:
>Peter,
>
>> I have also been thinking that a PI that sets the formatter maybe a good
>> idea. Currently I run all my ant output through awk to rewrite
>> "build/src/"
>> to "src/main" again to make it emacs friendly. Because then when you click
>> goto error it goes to error in original source rather than in src that has
>> been copied into build sub-directory. Is it worth making this a seperate
>> Logger ?
>>
>
>Is this an issue when building ant or other projects. Why is the source
>being
>copied at all?
I don't know why it is done but it seems to be done in all apache projects.
I was under impression it was because some os doesn't support timestamps
well or kept locking files or some other reason. The result is that all src
files are usually copied to build/src and then compiled from there. I
noticed a few complaints from people when I didn't imitate this with my own
stuff because sometimes it wont rebuild dependancies properly. So I guess
it has something to do with that ????
Thus when a error occurs it occurs in
build/src/com/company/file.java and not src/com/company/file.java. Hence
when I hit the emacs key that takes you straight to line with error it
takes me to wrong copy and a few times I have lost everything as i hit
compile and the one in build/src gets copied over from src/
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Recent logging aint emacs friendly
Posted by Jeff Turner <je...@socialchange.net.au>.
Conor MacNeill wrote:
>
> Peter,
>
> > I have also been thinking that a PI that sets the formatter maybe a good
> > idea. Currently I run all my ant output through awk to rewrite
> > "build/src/"
> > to "src/main" again to make it emacs friendly. Because then when you click
> > goto error it goes to error in original source rather than in src that has
> > been copied into build sub-directory. Is it worth making this a seperate
> > Logger ?
> >
>
> Is this an issue when building ant or other projects. Why is the source
> being
> copied at all?
I always assumed it was so you could filter your code, replacing
@date@ with the current date, etc. I use this to insert the build
number into code, by incrementing a variable in build.sh, and passing
it as a parameter to Ant.
--Jeff
RE: Recent logging aint emacs friendly
Posted by Conor MacNeill <co...@m64.com>.
Peter,
> I have also been thinking that a PI that sets the formatter maybe a good
> idea. Currently I run all my ant output through awk to rewrite
> "build/src/"
> to "src/main" again to make it emacs friendly. Because then when you click
> goto error it goes to error in original source rather than in src that has
> been copied into build sub-directory. Is it worth making this a seperate
> Logger ?
>
Is this an issue when building ant or other projects. Why is the source
being
copied at all?
Recent logging aint emacs friendly
Posted by Peter Donald <do...@mad.scientist.com>.
Hi,
Th recent loggin addition is not emacs friendly at all. Would it be
possible to change the DefaultLogger so that it doesn't output " [task] "
at front of log messages. Alternatively it could be made dependant on a
property/PI ???
I have also been thinking that a PI that sets the formatter maybe a good
idea. Currently I run all my ant output through awk to rewrite "build/src/"
to "src/main" again to make it emacs friendly. Because then when you click
goto error it goes to error in original source rather than in src that has
been copied into build sub-directory. Is it worth making this a seperate
Logger ?
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Javadoc task: author and version should be unset by default
Posted by Ernst de Haan <er...@jollem.com>.
Hi Peter && all,
Well, I had not yet thought about that, but considering it, I don't
think the Javadoc task currently supports the passing of parameters to
custom doclets.
Implementing this feature may indeed involve quite some hassle. But it
is the way the go IMHO. I do not know how subtags are implemented in
Ant, so I'll look into that first before writing a diff. That is, if
this is considered the `way to go' ;'/ Any comments?
Ernst
Peter Donald wrote:
> At 10:48 8/7/00 +0200, you wrote:
> >Yes that does make sense :) I've attached a diff that does what you
> >want. Still I feel that this makes things more complicated than they
> >should be, because the default behaviour of the standard doclet is to
> >_not_ include author and version info, but on the other hand I don't
> >think it's a big issue.
>
> I have my own doclet and had to jump through hoops to get it working
> aswell. What I wanted to do - thou I never got around to it wast to enable
> something like
>
> <javadoc ...base-tool-parameters-here...>
> <doclet-param name="author" value="true" />
> <doclet-param name="myCustomFunkyTag" value="true" />
> ...
> </javadoc>
>
> Would this solve your problems aswell ???
>
>
> Cheers,
>
> Pete
>
> *------------------------------------------------------*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power." |
> | -Abraham Lincoln |
> *------------------------------------------------------*
RE: Javadoc task: author and version should be unset by default
Posted by Conor MacNeill <co...@m64.com>.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@mad.scientist.com]
> Sent: Saturday, 8 July 2000 19:00
> To: ant-dev@jakarta.apache.org
> Subject: Re: Javadoc task: author and version should be unset by default
>
>
> At 10:48 8/7/00 +0200, you wrote:
> >Yes that does make sense :) I've attached a diff that does what you
> >want. Still I feel that this makes things more complicated than they
> >should be, because the default behaviour of the standard doclet is to
> >_not_ include author and version info, but on the other hand I don't
> >think it's a big issue.
>
> I have my own doclet and had to jump through hoops to get it working
> aswell. What I wanted to do - thou I never got around to it wast to enable
> something like
>
> <javadoc ...base-tool-parameters-here...>
> <doclet-param name="author" value="true" />
> <doclet-param name="myCustomFunkyTag" value="true" />
> ...
> </javadoc>
>
> Would this solve your problems aswell ???
I have just committed a patch which provides similar facilities to this.
For Ernst's doclint doclet it works like this
<target name="main">
<javadoc packagenames="org.apache.tools.*,com.oreilly.servlet.*"
sourcepath="../jakarta-ant/src/main">
<doclet name="com.jollem.doclint.DocLint"
path="E:\doclint\doclint.jar">
</doclet>
</javadoc>
</target>
Ernst,
I left the settings for author and version as true but added the doclet
check. I don't know if anyone is relying on them being set to true by
default.
dolint seems pretty cool, BTW.
Conor
Re: Javadoc task: author and version should be unset by default
Posted by Peter Donald <do...@mad.scientist.com>.
At 10:48 8/7/00 +0200, you wrote:
>Yes that does make sense :) I've attached a diff that does what you
>want. Still I feel that this makes things more complicated than they
>should be, because the default behaviour of the standard doclet is to
>_not_ include author and version info, but on the other hand I don't
>think it's a big issue.
I have my own doclet and had to jump through hoops to get it working
aswell. What I wanted to do - thou I never got around to it wast to enable
something like
<javadoc ...base-tool-parameters-here...>
<doclet-param name="author" value="true" />
<doclet-param name="myCustomFunkyTag" value="true" />
...
</javadoc>
Would this solve your problems aswell ???
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Javadoc task: author and version should be unset by default
Posted by Ernst de Haan <er...@jollem.com>.
Conor,
Yes that does make sense :) I've attached a diff that does what you
want. Still I feel that this makes things more complicated than they
should be, because the default behaviour of the standard doclet is to
_not_ include author and version info, but on the other hand I don't
think it's a big issue.
But if the user could somehow set the default doclet to something else
than the standard doclet (or a derivate), then we would run into
trouble, since I do not see a means to detect that situation.
I have tested this new version of the Javadoc task with my custom
doclet. See http://www.znerd.demon.nl/doclint/ for a description of the
doclet, a download link and info on how to use this doclet with Ant.
PS: I've also updated the documentation for the JavaDoc class, to make it more
readable and to include information on what changes I made.
Ernst
Conor MacNeill wrote:
> Ernst,
>
> Before I apply your patch, I'd like to discuss the issue a little more.
> According to the Javadoc documentation many options are provided by the
> standard doclet. If I read the doc correctly they are these.
>
> -d -use -version -author -splitindex -windowtitle -doctitle
> -title -header -footer -bottom -link -linkoffline -group
> -nodeprecated -nodeprecatedlist -notree -noindex -nohelp
> -nonavbar -helpfile -stylesheetfile -serialwarn -charset
> -docencoding
>
> One option would be to leave all of these out if the doclet parameter is
> set. As a doclet writer can you tell us whether that would make sense.
>
> Conor
> --
> Conor MacNeill
> Home: conor@m64.com
> Work: conor@cortexebusiness.com.au
> Web: www.cortexebusiness.com.au
>
>
> > -----Original Message-----
> > From: Ernst de Haan [mailto:ernst@jollem.com]
> > Sent: Saturday, 8 July 2000 8:46
> > To: Ant Development
> > Subject: Javadoc task: author and version should be unset by default
> >
> >
> > Hi,
> >
> >
> > I am currently developing an open-source JavaDoc check tool, called
> > DocLint. I use Ant both for building DocLint, and for checking the
> > JavaDoc comments of other projects. I implemented DocLint as a doclet,
> > so for the checking I used the `javadoc' task and set the `doclet' and
> > `docletpath' properties.
> >
> > But what I found out when I tried to let Ant do the checking, that the
> > `version' and `author' properties are set to `yes' by default. But these
> > properties are only valid for the standard doclet, not for doclets in
> > general. So IMHO these properties should be unset.
> >
> > I have attached a diff file (the result of cvs diff).
> >
> >
> > Ernst
> >
>
RE: Javadoc task: author and version should be unset by default
Posted by Conor MacNeill <co...@m64.com>.
Ernst,
Before I apply your patch, I'd like to discuss the issue a little more.
According to the Javadoc documentation many options are provided by the
standard doclet. If I read the doc correctly they are these.
-d -use -version -author -splitindex -windowtitle -doctitle
-title -header -footer -bottom -link -linkoffline -group
-nodeprecated -nodeprecatedlist -notree -noindex -nohelp
-nonavbar -helpfile -stylesheetfile -serialwarn -charset
-docencoding
One option would be to leave all of these out if the doclet parameter is
set. As a doclet writer can you tell us whether that would make sense.
Conor
--
Conor MacNeill
Home: conor@m64.com
Work: conor@cortexebusiness.com.au
Web: www.cortexebusiness.com.au
> -----Original Message-----
> From: Ernst de Haan [mailto:ernst@jollem.com]
> Sent: Saturday, 8 July 2000 8:46
> To: Ant Development
> Subject: Javadoc task: author and version should be unset by default
>
>
> Hi,
>
>
> I am currently developing an open-source JavaDoc check tool, called
> DocLint. I use Ant both for building DocLint, and for checking the
> JavaDoc comments of other projects. I implemented DocLint as a doclet,
> so for the checking I used the `javadoc' task and set the `doclet' and
> `docletpath' properties.
>
> But what I found out when I tried to let Ant do the checking, that the
> `version' and `author' properties are set to `yes' by default. But these
> properties are only valid for the standard doclet, not for doclets in
> general. So IMHO these properties should be unset.
>
> I have attached a diff file (the result of cvs diff).
>
>
> Ernst
>