| Re: [aspectj-dev] Compiling and not weaving |
I don't fully get the compile step, and why not weaving leads to
unexecutable code, since it should be similar to compiling @AspectJ
classes with a common compiler and then weave them in using LTW. But
before asking you more details I'll go read the code and try to figure
it out by myself.
> <mailto:andrew.clement@xxxxxxxxx>>
Andy Clement wrote:
> Oh... let me also add that a better split matching/weaving process is
> under development. From the project plans on
>
> http://www.eclipse.org/projects/project-plan.php?projectid=tools.aspectj
>
> There is a reference to bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=246125
>
> which discusses breaking out the matcher for standalone reuse and thus
> enabling better tools for development of code that will be load-time
> woven later on.
>
> cheers,
> Andy.
>
> 2008/10/3 Andy Clement <andrew.clement@xxxxxxxxx
> <mailto:simoneg@xxxxxxxxxx>>>
> Hi Simone,
>
> Have you tried turning off pipeline compilation as well as using
> terminateAfterCompilation? The latter worked perfectly until the
> former was invented - now they may be interfering.
> -XterminateAfterCompilation is not really intended for end users
> and so I have never gotten around to fixing it in relation to
> pipelining.
>
> > - Simulate weaving, both on local classes and on inpath, but
> output only
> > warnings and errors, and don't weave classes
> >
> > Which is somehow similar to what -XterminateAfterCompilation is
> supposed
> > to do, except the simulate weaving part.
>
> -XterminateAfterCompilation is what we used to call noweave and I
> renamed it because I didn't want people incorrectly using it
> because they didn't really know what it did.
> -XterminateAfterCompilation is for me to debug code that came out
> of the compiler before it goes into the weaver, it has no other
> goal than that. And the code that comes out of the compiler in
> some cases (eg. aspects) is incomplete and will not run until the
> weaver has finished it off.
>
> Simulating weaving is currently not easy as the matching and
> weaving are relatively tied together.
>
> The use of ITDs to complete the type system already happens, they
> are 'simulated' during compilation so that we know the type system
> is coherent and then woven in later at weave time.
>
> I'm afraid your setup is a bit too complicated for me to
> understand, any chance of a test case that shows what you want the
> compiler to do?
>
>
> > I think such a feature is needed. Basically, it is something like :
> > - Take this aspectpath
> > - Take these .java and .aj
> > - Take this -inpath
> > - Compile the .java and .aj, taking into consideration the ITD
> present in aspects
> > - DO NOT weave those ITD inside the resulting class files, use
> them only
> > to check possible compilation errors.
> > - DO NOT weave advice in resulting class files
> > - DO NOT weave advice on classes in -inpath
>
> this is what -XterminateAfterCompilation does.
>
> > - Use the -inpath only to properly generate warnings and errors.
>
> -XterminateAfterCompilation will only generate warnings and errors
> for things found at compilation time, nothing for weave time, not
> even for matching.
>
> > Also, it throws a number of exception inside the aj compiler, null
> > pointer mostly, probably while trying to resolve some ITD.
>
> What are these? -XterminateAfterCompilation shouldn't NPE. As i
> say, the code that comes out will not necessarily run but nothing
> should go wrong at compile time - please try it with also turning
> off pipeline compilation.
>
> cheers,
> Andy.
>
> 2008/10/3 Simone Gianni <simoneg@xxxxxxxxxx
> aspectj-dev@xxxxxxxxxxx <mailto:aspectj-dev@xxxxxxxxxxx>>
> Hi all,
> my situation is the following :
> - I have several different projects
> - each one is built with maven
> - as such, it declares dependencies on other projects
> - every project can contain classes, advice and inter type
> declarations
> (both public and private methods and fields)
> - these projects will be then loaded together using LTW in an
> application, OR they will be completely weaved each one on
> each other by
> an external process to produce a "final version".
>
> Up to this, no problem at all. Building it with maven will
> simply work,
> produce all the artifacts and so on, provided that all relevant
> dependencies are present in -aspectpath and nothing is present in
> -inpath (otherwise, multiple copies of the same classes, weaved -
> partially weaved - non weaved at all, will be included in the
> resulting
> jars.
>
> Then, loading it with LTW will "finish" the weaving process,
> making
> aspects defined in some projects also weave classes from
> projects they
> depend to.
>
> I know this explanation is getting complicated, it is not so hard,
> please have the patience to keep reading another minute.
>
> The problem arise when ONLY ONE of the projects is modified
> and then
> deployed. For example, if a project redefined an advice to
> match other
> methods than before, the old jars of other projects will still
> contain
> calls to the old advice, and often fail at runtime. Also, we are
> currently receiving an incredible number of
> Xlint:adviceDidNotMatch
> cause our inpath is empty, to avoid class duplication.
>
> These are major problems, cause we need to rebuild everything
> every time
> a single project releases a new version, or even just to test
> when other
> projects are involved in the test, and have no clue wether or
> not we
> mispelled something in a pointcut, cause
> Xlint:adviceDidNotMatch will
> always be warned,
>
> I tried the -XterminateAfterCompilation switch. It does what it is
> designed for, and produced classes does not contain calls to
> advice, BUT
> it also misses all static intertype declarations, so projects
> depending
> on the presence of a method declared using intertype
> declaration or on a
> certain object implementing a certain interface will fail.
>
> Also, it throws a number of exception inside the aj compiler, null
> pointer mostly, probably while trying to resolve some ITD.
>
> I think such a feature is needed. Basically, it is something
> like :
> - Take this aspectpath
> - Take these .java and .aj
> - Take this -inpath
> - Compile the .java and .aj, taking into consideration the ITD
> present
> in aspects
> - DO NOT weave those ITD inside the resulting class files, use
> them only
> to check possible compilation errors.
> - DO NOT weave advice in resulting class files
> - DO NOT weave advice on classes in -inpath
> - Use the -inpath only to properly generate warnings and errors.
>
> This seems to be somehow similar to :
> - Compile, as always
> - Simulate weaving, both on local classes and on inpath, but
> output only
> warnings and errors, and don't weave classes
>
> Which is somehow similar to what -XterminateAfterCompilation
> is supposed
> to do, except the simulate weaving part.
>
> Is this a reasonable feature to add to AspectJ? More than a
> new feature,
> I think it should be the way -XterminateAfterCompilation works
> anyway.
> This is absolutely needed to have AspectJ and Maven cooperate
> well in a
> project that goes even just a step after the "tracing aspect"
> kind of
> organization.
>
> Is this something I can try to do on my own? I've been reading
> AspectJ
> code lately, but before working on such a (for me big)
> change/fix/feature would like to know if there is any interest
> on it
> and/or any known problems that would prevent it to work correctly.
>
> Simone
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache
> Committer
> MALE human being programming a computer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-dev mailing list
> ------------------------------------------------------------------------
>--
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
Simone Gianni CEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev