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>
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
