ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject beyond Javac semantics using CompilerAdapter
Date Tue, 05 Nov 2002 15:15:19 GMT
Looking at the nicely-extensible Javac/CompilerAdapter code,
what's the best way to implement an interface to a compiler 
that has options beyond Javac's?

The eclipse compiler has a host of non-Javac options
(and some remappings of the same options), and the
AspectJ compiler has 3-4 more.  Approaches I garnered:

1 support an "argument" file (prefixed with @, used
  by javac, ajc, and jikes) which contains an arbitrary
  set of args/options.

  a) extract this from the list of unflagged arguments
     --> unable to do this.  Javac.scanDir() controls files
         admitting only *.java.

  b) support a single additional argument -- setArgfile(Path)

2 Use Facade, and implementation-specific arguments
  @see ImplementationSpecificArgument Javac.createCompilerArg()
  ?? but this seems to be limited to the compilers recognized
     by Ant, and would not work for a user-supplied compiler

3 Don't use Javac; write a taskdef directly.
  This is really bad because we'd like users to be able to
  compile using their existing builds by only changing the 
  compiler attribute.

Are there other/better approaches?  best-available sample code?
Advice on picking/executing an approach?

Thanks -

P.S. - Current taskdef attempts are available at the bottom of

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message