Re: [aspectj-dev] "noweave" use case

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

Hi Ram -

There are some issues with the -Xnoweave option that we won't
have the time to carefully resolve for 1.1, even though, 
as you suggest, there may be times when it would be useful.

The workaround at present is to weave tracing into transactions 
when the transactions jar is compiled. e.g.,

-- do the build
  ajc @tracing.lst -outjar tracing.jar
  ajc @transactions.lst -aspectpath tracing.jar \
      -outjar transactions.jar
  ajc @app.lst -aspectpath "tracing.jar;transactions.jar" \
      -outjar app.jar
-- build the jar
  mkdir final
  cd final
  jar xf ../tracing.jar
  jar xf ../transactions.jar
  jar xf ../app.jar
  # fixup manifest, etc?
  jar cf ../final.jar *

What if you don't have the sources for the transactions.jar?
This is a case of getting binary transactions aspects from a 
vendor who won't provide source and wanting to weave your 
tracing into it.  I would hope that by the time that problem 
becomes prevalent, we will have a solution for it.

If you'd like to keep this on the radar, please submit this
discussion as an RFE for the compiler at

  http://dev.eclipse.org/bugs/enter_bug.cgi?product=AspectJ

Thank you -
Wes

P.S. - Personally, I think this case

> > ajc -injars app.jar;transaction.jar
>       -aspectpath transaction.jar;tracing.jar

doesn't make sense.  Things on the aspectpath are defined,
whereas things in injars will be woven into and redefined.
It's not clear from this command which variant the user 
expects when refering to a type in transactions.jar.

Ramnivas Laddad wrote:
> 
> Hello,
> 
> I think I have a use case that cannot be implemented
> (at least elegantly, anyway) without noweave/XnoWeave
> option (and thus I request to make it a regular option
> instead of experimental -X).
> 
> Basically, I want to have my tracing.jar (
> contains tracing aspect) weave into transaction.jar
> (contains abstract transaction mangement aspects,
> concrete policy enforcement aspects, and supporting
> classes). Assume app.jar contain business classes
> and interfaces. Each of the jar is created using
> -ourjar (but not -noweave or -XnoWeave).
> 
> To build the final system I issue the following
> command:
> > ajc -injars app.jar;transaction.jar
>       -aspectpath transaction.jar;tracing.jar
> 
> Now compiler gives me error due to multiply woven
> classes and aspects in transaction.jar.
> 
> Everything works fine if I create the original jar
> files using -noweave.
> 
> I could workaround by creating multiple jars, but
> I hink -noweave is the right approach as
> I really don't want to ship multiple jars that are
> needed to implement a single concern and expect the
> users to correctly specify jar files in -injars
> and -aspectpath.
> 
> -Ramnivas
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev