> Doug Kramer wrote:
> Have you tried:
> javadoc -tag "ejb:bean":X
> There is a bug in 1.4.1 and 1.4.0 where the X term does not work unless it
> is followed by a name, so also try:
> javadoc -tag "ejb:bean":X:bean
Michael Pichler wrote: <###@###.###>
I tried, but it did not work. Either the quote " is interpreted solely by the
shell or - when quoted - javadoc thinks the user means a tag @"ejb (still
truncated at the first ":" character, not searching for a matching ").
Perhaps the -tag argument parsing should allow for a quoting character, e.g.
(two \\ on the commandline such that the shell passes one \ to javadoc).
> Doug wrote:
> Can you think of any objection to allowing the colon in such a tag name?
I can't think of any reason not to allow this. The tool has always been able to
handle tags with colons in them. If the tool allows this, then the doclet
should support this.
> I realize the colon is not allowed in class names, and wonder if we
> should keep the same constraint for tag names.
> The colon in custom tags that are interpreted by a third-party doclet
> called "xdoclet", so there is some benefit to allowing the use of a
> colon, as those tags could also be used by the standard doclet.
It sounds like there is a need for our doclet to support this. If people are
already using tags like this, our doclet should be able to handle them.
> The complication seems to be that the colon is passed in on the
> command line as:
> javadoc -tag "ejb:bean":a:bean
> where it is interpreted by some shells rather than passed along.
> Is there an escape character that would work to escape the colon,
> such as "\:" or "\\:"?
I think that we would have to use "\\:" because the first \ is probably thrown
away by the shell before the string is passed to Javadoc. Maybe we can support
"-" as a seperator. For example:
-tag "ejb:bean-a-EJB Beans:"
If "-" is found in the string, it is assumed that "-" is the seperator, not ":".
We should add some documentation for this. We no longer support dashes as
seperators for the tag option due to the regression it caused that we fixed
in Nov 2003:
4920381: REGRESSION: Tag name containing dash not allowed.
The colon is now ALWAYS the seperator. If the
user wants a colon in their tag name, they have to escape it using the
It was a bad idea to use an alternate seperator. That just introduces a
different bug. I think escaping is the right fix.