You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Conor MacNeill <co...@m64.com> on 2000/06/29 17:37:00 UTC
Javadoc patch
I have applied Patrick's Javadoc patch with a few changes.
I change the nested elements from
<groups> to <group>
<links> to <link>
<linkofflines> to <link offline="yes">
This seems a little clearer to me since each element only describes a single
link or group. I know Patrick wanted to distinguish the nested element from
the attribute but I think it is still clear. Combining the two link types
into a single element seemed logical and makes it easy to change from the
offline form to the online form.
I also added support for multiple source paths. To do this I added my
PathTokenizer object which I have previously discussed.
Let me know if there are any issues.
Conor
RE: Javadoc patch
Posted by Peter Donald <do...@mad.scientist.com>.
At 08:57 3/7/00 +0930, you wrote:
>Is c:d:\path a valid path on DOSalike systems? I'd have thought
>c:;d:\path would be the way to express that; c:d:\path isn't really
>valid on anything, is it?
It is legal on unix. It refers to the three paths "c", "d" and "path" (the
\p --> p because escaped p is plain old everyday p :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: Javadoc patch
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Tom,
Ant tries to be very accommodating with regard to paths. So it will try to
interpret paths using both : or ;. Also paths may be put together with
fragments from different systems.
As an example, say you have the following
<property name="classes" value="c"/>
<property name="build.classpath" value="${classes}:${junit.home}"/>
Where c is a subdirectory containing your classes and junit.home is supposed
to be passed in from the external environment. If on a windows system you
set junit.home to d:\path (say its some project wide environment variable),
then the resulting value of build.classpath is
c:d:\path.
I would want that to be understood as a path consisting of c and d:\path.
Cheers
Conor
--
Conor MacNeill
conor@cortexebusiness.com.au
Cortex eBusiness
http://www.cortexebusiness.com.au
> -----Original Message-----
> From: Tom Cook [mailto:tcook@ardec.com.au]
> Sent: Monday, 3 July 2000 9:28
> To: ant-dev@jakarta.apache.org
> Subject: RE: Javadoc patch
>
>
> Conor MacNeill writes:
> [snip]
> > > (2) I feel returning the lookahead String in nextToken instead of
> > > scanning for a DOS path could be wrong in very strange cases (take
> > > c:d:\path for example, this would return c, d, \path). I could be
> > > wrong but maybe make it something like
>
> Is c:d:\path a valid path on DOSalike systems? I'd have thought
> c:;d:\path would be the way to express that; c:d:\path isn't really
> valid on anything, is it?
>
> Regards
> Tom
>
>
RE: Javadoc patch
Posted by Tom Cook <tc...@ardec.com.au>.
Conor MacNeill writes:
[snip]
> > (2) I feel returning the lookahead String in nextToken instead of
> > scanning for a DOS path could be wrong in very strange cases (take
> > c:d:\path for example, this would return c, d, \path). I could be
> > wrong but maybe make it something like
Is c:d:\path a valid path on DOSalike systems? I'd have thought
c:;d:\path would be the way to express that; c:d:\path isn't really
valid on anything, is it?
Regards
Tom
RE: Javadoc patch
Posted by Conor MacNeill <co...@m64.com>.
Stefan,
> >>>>> "CM" == Conor MacNeill <co...@m64.com> writes:
>
> CM> I also added support for multiple source paths. To do this I
> CM> added my PathTokenizer object which I have previously discussed.
>
> CM> Let me know if there are any issues.
>
> Sorry, Connor, must have missed that discussion. Two issues:
>
Thomas and I discussed it a little in the context of his Path proposal. It
can probably go away in the future ... when that stuff is available.
> (1) is there any reason to make tokenizer and lookahead package
> private instead of private?
No - an oversight on my part.
>
> (2) I feel returning the lookahead String in nextToken instead of
> scanning for a DOS path could be wrong in very strange cases (take
> c:d:\path for example, this would return c, d, \path). I could be
> wrong but maybe make it something like
>
Yes, you are right and I have made the change.
> Stefan
>
Re: Javadoc patch
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "CM" == Conor MacNeill <co...@m64.com> writes:
CM> I also added support for multiple source paths. To do this I
CM> added my PathTokenizer object which I have previously discussed.
CM> Let me know if there are any issues.
Sorry, Connor, must have missed that discussion. Two issues:
(1) is there any reason to make tokenizer and lookahead package
private instead of private?
(2) I feel returning the lookahead String in nextToken instead of
scanning for a DOS path could be wrong in very strange cases (take
c:d:\path for example, this would return c, d, \path). I could be
wrong but maybe make it something like
String token;
if (lookahead != null) {
token = lookahead;
lookahead = null;
} else {
token = tokenizer.nextToken().trim();
}
and move the rest out of the else branch?
I'm not sure I'm missing something here so I didn't change it myself.
Stefan
Re: Javadoc patch
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "CM" == Conor MacNeill <co...@m64.com> writes:
>> > <linkofflines> to <link offline="yes">
CM> Patrick has suggested that this may be undesirable because ant
CM> would no longer match (one to one) the command line options of
CM> the Javadoc tool.
I prefer your version (one tag with additional attribute). I feel it
covers the intention of javadoc better.
Stefan
RE: Javadoc patch
Posted by Conor MacNeill <co...@m64.com>.
> As of distinguishing the attribute name of link and group from the nested
> element name, I had no ideological opinion about it: it is just that in my
> tests, it appeared that if they have the same name, an old
> build.xml file using
> the attribute would not work anymore: you would get an exception.
> And backward compatibility seems to me a very important requirement.
>
OK, it works for me on NT with combinations of link or group as attributes
and nested elements. From what I understand of the parsing, I do expect it
to work. Nevertheless let me know if it is an issue for anyone. Backward
compatibility is an important requirement (though not a prison :-).
> Did you test that scenario ?
> If so I'm very happy with the solution.
> If not I suggest you change the name of the nested elements.
>
Let me know how it goes in your environment.
> > <linkofflines> to <link offline="yes">
Patrick has suggested that this may be undesirable because ant would no
longer match (one to one) the command line options of the Javadoc tool. I
think that is an important point. I still feel, however, that it is a more
natural way of expressing the ideas. After all we can be more expressive in
the XML than is possible with command line switches. What do others think?
Conor
Re: Javadoc patch
Posted by Patrick Chanezon <ch...@netscape.com>.
Hi Conor,
thanks for commiting that patch, my project will now be able to update to the
latest ant release.
As of distinguishing the attribute name of link and group from the nested
element name, I had no ideological opinion about it: it is just that in my
tests, it appeared that if they have the same name, an old build.xml file using
the attribute would not work anymore: you would get an exception.
And backward compatibility seems to me a very important requirement.
Did you test that scenario ?
If so I'm very happy with the solution.
If not I suggest you change the name of the nested elements.
P@
Conor MacNeill wrote:
> I have applied Patrick's Javadoc patch with a few changes.
>
> I change the nested elements from
>
> <groups> to <group>
> <links> to <link>
> <linkofflines> to <link offline="yes">
>
> This seems a little clearer to me since each element only describes a single
> link or group. I know Patrick wanted to distinguish the nested element from
> the attribute but I think it is still clear. Combining the two link types
> into a single element seemed logical and makes it easy to change from the
> offline form to the online form.
>
> I also added support for multiple source paths. To do this I added my
> PathTokenizer object which I have previously discussed.
>
> Let me know if there are any issues.
>
> Conor
--
Patrick Chanezon, iPlanet Market Maker- Portal/EServices Technical Lead
Netscape Communications Corp. - http://people.netscape.com/chanezon/
Opinions are my own.
"Two monks were arguing about a flag. One said: `The flag is moving.'
The other said: `The wind is moving.'
The sixth patriach happened to be passing by. He told them: `Not the wind, not
the flag; mind is moving.'"
Zen Koan