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.)
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.)
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