> Some aspects or classes are already woven before the ITD they rely on has > happened.
For a particular compilation we collect up all the aspects we know about. We then apply all the aspects affecting the type structure (inter type declarations, declare parents), then later we apply the advice. If you are describing a two step process where a compile step is relying on something done via ITD in a later compile step, that is a bit dodgy, but it might work due to reweaving. Since when the ITDs are applied in that second compile we revert all classes back to their pre-weaving state and apply the new aspects alongside the old aspects - effectively we are discarding whatever the initial compile did. cheers, Andy > On Apr 3, 2015, at 6:07 AM, Alexander Kriegisch <alexan...@kriegisch.name> > wrote: > > I have checked out Romain's project from here: > svn://svn.code.sf.net/p/zvtm/code/ zvtm-code > > What I saw is that module zvtm-cluster wants to weave ITD methods into > zvtm-core. There are other aspects relying on ITD-ed methods introduced by > other aspects. There seems to be something wrong with the compilation order. > Some aspects or classes are already woven before the ITD they rely on has > happened. @Andy: Is this something which is to be expected to work? I tried > with AspectJ Maven Plugin 1.7 and AspectJ 1.8.5 dependencies for both the > plugin and the runtime. > -- > Alexander Kriegisch > http://scrum-master.de > > > Andy Clement schrieb am 03.04.2015 00:59: > > And worth looking at the 1.6.8 readme: > http://eclipse.org/aspectj/doc/released/README-168.html > <http://eclipse.org/aspectj/doc/released/README-168.html> >> >> >> It starts with: >> >> >> The first sentence in the 1.6.7 readme was 'AspectJ 1.6.7 includes some >> radical internal changes.' >> >> Unfortunately not enough testing was done on 1.6.7 and two nasty issues were >> found that really needed addressing. Fixes for these issues are all that is >> new in 1.6.8. >> >> >> So I wouldn’t use 1.6.7. But really you ought to move to 1.8.5 if you can. >> I won’t be able to fix anything on 1.6.X if you hit something, I’d fix it >> for 1.8.6. >> >> >> cheers, >> >> Andy >> >> >>> On Apr 2, 2015, at 1:02 PM, Alexander Kriegisch <alexan...@kriegisch.name >>> <mailto:alexan...@kriegisch.name> > wrote: >>> >>> >>> Hi Romain. >>> >>> >>> Is there any specific reason for you to use an AspectJ version from 2009? >>> How about giving 1.8.5 a try? >>> >>> >>> Disregarding the version, do you think you can share your aspect(s) and >>> target class(es), ideally a minimal example reproducing the problem? Even >>> though you say it is unrelated, the Maven POM would also be interesting. >>> >>> >>> As for 1.6.6 to 1.6.7 behaviour changes: >>> http://eclipse.org/aspectj/doc/released/README-167.html >>> <http://eclipse.org/aspectj/doc/released/README-167.html> >>> >>> -- >>> >>> Alexander Kriegisch >>> >>> >>> Schillerplatz 6, 91315 Höchstadt, Germany <x-apple-data-detectors://5/0> >>> >>> Tel +49 (9193) 52 76, Mob +49 (176) 20 53 07 02 >>> <tel:+49%20(176)%2020%2053%2007%2002> >>> >>> >>> Am 02.04.2015 um 21:10 schrieb Romain Primet <romain.pri...@gmail.com >>> <mailto:romain.pri...@gmail.com> >: >>> >>> >>>> Hi list, >>>> >>>> >>>> I have an aspectJ-based codebase that currently uses 1.6.6 (compiler and >>>> runtime) and builds fine. >>>> >>>> Moving to 1.6.7+, I get errors related to inter-type declarations. >>>> Specifically, a library is being weaved by an aspect that declares a new >>>> parent for an existing class. This parent supplies three public methods >>>> that are called by other aspects and by Java code. These methods are found >>>> when using 1.6.6, but not by 1.6.7+ ("[ERROR] The method isReplicated() is >>>> undefined for the type Glyph"). >>>> >>>> The build is managed by Maven, but running ajc directly (using the command >>>> output by mvn -X) yields the same results. >>>> >>>> Trying to restrict the build to the classes and aspects that relate only >>>> to the ITD (i.e. not the users of the introduced methods) works, even for >>>> 1.6.7+. The generated classes inherit the superclass as expected. >>>> >>>> Beyond using -showWeaveInfo (which is enabled but unfortunately yields no >>>> results), is there something I can do to pinpoint the problem? >>>> >>>> It's a bit hard to prune to a minimal test case but the code is available >>>> in case someone wants to take it for a spin. >>>> >>>> Apologies if I'm unclear and/or off-topic. >>>> >>>> Cheers! >>>> >>>> Romain >>>> _______________________________________________ >>>> aspectj-users mailing list >>>> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>>> <https://dev.eclipse.org/mailman/listinfo/aspectj-users> >>>> >>> >>> _______________________________________________ >>> aspectj-users mailing list >>> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> >> > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
