On 3/2/06, Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_sun.com> wrote:
>
> Malachi de Ælfweald wrote:
> > Actually.... If we were to have the args4j @Option tags on a base class
> > that both referenced... Could we easily autogenerate an Ant task and
> Maven
> > Mojo using reflection?
>
> For simple properties like boolean, string, etc, this works just fine.
> But when it gets complicated, like FileSet, or list of arguments, etc,
> then I don't know if it's really all that easy.
>
> I tried to extend args4j so that I can use the same annotated option
> bean for both CLI and Ant, but I quickly found that it's not that simple
> for non-trivial ant tasks (like XJC.) So I still haven't able to figure
> that out yet.
>
> But you are right that that might be another way to solve this problem.
> The point of reusing the Ant syntax is primarily so that we don't have
> to maintain different option parsing code. So if we can extend args4j
> (or come up with something simliar) that allows us to unify
> CLI/Ant/Maven, the syntax that the user uses could be very different.
As 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....
IE: We edit XjcDriver.java which has @Option tags
and our build auto-generates Xjc2Task, Xjc2Mojo, Xjc2CLI, whatever....
Mal