Re: [aspectj-dev] Binary Weaving: Class-Path JAR Manifest Attribute

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

Mik: To amplify what Matthew might have meant by his title:
This might also be among the options that make sense only or primarily
to a binary weaver.  I believe the weaver can work without the
compiler, and that we haven't surfaced an official API for it.  This
option might be one to restrict to the weaver API, and pull into
the compiler only as needed.  You might pull it in when editing
the classpath in the project, with a checkbox for generating
additional entries for those referenced in input jar manifests.

Matthew:
I like this because a weaving class loader should behave like the
java VM with respect to what classes it can load.  But as a build
or compiler option, we should be able to disable it, to avoid
unintended library conflicts.

However, I don't understand this:

>>Doing this would also require a change to the current resource copying
>>behaviour.

Don't we now "handle" manifest collisions like other resource
collisions, with first-wins and warn thereafter?

Wes

Mik Kersten wrote:
> Hi Matthew,
>
> Although I haven't encountered need for this, it could be a good idea.
> Setting up injar dependencies this way makes sense to me on the command
> line, but I have questions about how it will look for AJDT projects.  For
> example, if the injar specifies additional classes that end up getting
> advised by aspects in your project, the project won't know about them (since
> you declared the dependency in the injar manifest and not in the project
> properties).  So should this be targeted at the command-line only, or do you
> have an idea of how it should work within Eclipse?  Could you put together a
> use case along with the desired behavior and report it as an enhancement?
>
> I'm happy to help if you want to submit this as a patch.  On the surface it
> seems that when multiple injars are present the entries should be
> concatenated into the "Class-Path" attribute for the outjar.  Also,
> depending on how you want the dependencies to work, the injar might require
> the classes from "Class-Path" in order to compile.  If that's the case those
> paths to AjBuildConfig will be straightforward.  
>
> Mik
>
>
> > -----Original Message-----
> > From: aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx]
> > On Behalf Of Matthew Webster
> > Sent: Thursday, October 30, 2003 2:01 AM
> > To: aspectj-dev@xxxxxxxxxxx
> > Subject: [aspectj-dev] Binary Weaving: Class-Path JAR Manifest Attribute
> >
> > I think we should use the "Class-Path" attribute, if present, to augment
> > the classpath when binary weaving according to this specification:
> > "http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.html";. It is a
> > list of additional JARs needed to run the application given as a set of
> > relative URLs.
> >
> > Doing this would also require a change to the current resource copying
> > behaviour. We would need to copy the manifest from the injar to the outjar
> > but I not sure how to deal with multiple injars. Any thoughts?
> >
> > Matthew Webster
> > AOSD Project
> > Java Technology Centre, MP146
> > IBM Hursley Park, Winchester,  SO21 2JN, England
> > Telephone: +44 196 2816139 (external) 246139 (internal)
> > Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
> > http://w3.hursley.ibm.com/~websterm/
> >
> > _______________________________________________
> > aspectj-dev mailing list
> > aspectj-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev