Re: [aspectj-dev] -inpath ??

["Andrew Clement" <CLEMAS@xxxxxxxxxx>]

Hi Wes,

Thanks for your response.  I particular liked
the statement:

"changing a compiler option has not made one
responsible
 for all the downstream changes."

The option -inpath is now in the AspectJ codebase.
 It
expects something like a classpath, so either directories
or jar files - the contents of which will be used
as input
class files for the binary weaving process.  I
basically
searched for where injars was being handled and added
inpath support.  Things I have done:

- Added inpath to the options processing code and
  on the AJDE interface for exposure to the tools.
- Supplied some testcases in AJDE module tests
- Enhanced the ANT task to support the option

Things I haven't done :

- Documentation
   - devguide updates
   - readme for 1.2?
   - ant doc updates
- Verified the ANT task enhancements
- Upgraded the harness for inpath testing.

It was a tricky business as the changes for it are
so
crosscutting, touching multiple modules.  I didn't
want to wait until everything was done since it would
be a huge complex patch, so the minimum sensible piece
has been integrated first.

Any assistance from anyone out there with the other
todos would be appreciated :)

cheers,
Andy.

Wes Isberg <wes@xxxxxxxxxxxxxx> Sent by: aspectj-dev-admin@xxxxxxxxxxx 06/11/2003 23:09 Please respond to aspectj-dev

To:        aspectj-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [aspectj-dev] -inpath ??

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

_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev