Re: [aspectj-dev] -inpath ??

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

It sounds to me like you're already at the right solution:

- -injars will be supported but deprecated until we think
  no one's using it and bother to take it out.

- a new option -inpath will also take directories

- docs, test, and support:
  - devguide updates
  - readme for 1.2?
  - harness support
  - minimal test cases
  - ant task/doc updates
  - AJDE updates

In the past, changing a compiler option has not made one
responsible for all the downstream changes.

Wes

Andrew Clement wrote:
> Hi,
>
> As some of you know, I am looking at this feature.  The idea 
> is that we want to remove the requirement that users package
> up class files into a jar in order to do binary weaving.
> (Today, once they are packaged they are passed in on 
>  the -injars parameter)
>
> I just prototyped the support for allowing directories to be
> passed in, in addition to jars.  This means the compiler
> will weave into any class files it finds in the directory
> tree specified. 
>
> I just can't decide on the externals and am after 
> some opinions.
>
> My prototype extended -injars so that it allowed directories
> as well as zips/jars - so in fact -injars supports something
> like the classpath format now "a.zip;c:\mydir;b.jar".  It
> runs like this:
>
> ajc -injars c:\MyEclipseJavaProjectBinDir TracingAspect.java 
>
> Now, if only it was -inpath ...
>
> So these are the options I see:
> - Add a brand new -inpath option that supercedes -injars
> - Rename -injars to -inpath
> - Just leave it as prototyped where -injars has a 'looser'
>   (misleading!) meaning.
>
> I'm worried about the impact on:
> - migration of stuff already out there using the old option.
> - documentation of the option
> - amount of extra work I have to do !!! :)
>
> thanks,
> Andy.
> AJDT Development