On 3/2/06, Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_sun.com> wrote:
>
> Malachi de Ælfweald wrote:
> s per my last email, we would still have to maintain multiple versions if
> > we are supporting users using different tools (ie: can't do filesets in
> the
> > CLI version)... but, instead of expanding args4j, what about writing a
> tool
> > that uses reflection on the @Option annotations TO CREATE the source
> > versions of the other 3?
> >
> > IE: We only update the one that has the @Option tags, and then let the
> other
> > 2-3 (more if we support other tools or versions) versions be
> > autogenerated....
>
> When I tried to do it in args4j, the real complexity was not about
> having to process annotations at the runtime. If that were the case we
> could have solved it by just becoming a code generator, as you say.
> (That doesn't mean doing things at runtime is better; in fact for JAXB
> it's better for it to be a code generator to avoid adding another jar
> dependency which requires more legal work --- I'm just saying it's
> orthogonal issue.)
Well, I am talking about using the @Options for a code generator, not for
runtime.
The real trouble was to expand annotations, without making it
> complicated, to have enough information needed to do Ant option parsing.
>
> For example, the 'strict' mode is an "-extension" option in CLI, but in
> Ant it's an attribute that takes two values. There's no up-to-date check
> in CLI (that doesn't make sense in the CLI world.)
Right, so if we read XjcBase.class's @Option(name="strict")
and from it, autogenerated XjcMojo.java's boolean @parameter
and also from it, autogenerated Xjc2Task.java's Options.STRICT or
whatever...
IE: code generating all of the plugin SOURCE from a command base class with
all the annotations
then we could ensure that all of them stay in sync, right?
Or is this way too much work?
Hmm, but it still seems like doable as I write this now. Why didn't it
> work well before?
>
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
>
>