Yep sorry, my bad, this was a configuration issue on my side, the fix
worked.
Cheers !
2015-07-06 21:51 GMT+02:00 Andy Clement <andrew.clem...@gmail.com>:
> Hi Romain,
>
> It should be in - I can see the fix in the git log (although I wish we’d
> tracked this in a real bugzilla rather than just in email). Are you sure
> you aren’t hitting something new now, having changed a bit of code?
>
> cheers,
> Andy
>
> On Jul 6, 2015, at 5:33 AM, Romain Primet <romain.pri...@gmail.com> wrote:
>
> Hi Andy,
>
> Contacting you again abount this issue, did the fix make it into 1.8.6? We
> get the same errors at compile time.
>
> Cheers
>
> Romain
>
> 2015-04-12 19:53 GMT+02:00 Andy Clement <andrew.clem...@gmail.com>:
>
>> Nope I have no testcase, I couldn’t recreate it in a simple scenario
>> after trying for a little while so had to work on it in Romains complete
>> app. Sometimes I don’t have the cycles to get a lovely regression test in
>> place :(
>>
>>
>> cheers,
>> Andy
>>
>> > On Apr 12, 2015, at 8:02 AM, Alexander Kriegisch <
>> alexan...@kriegisch.name> wrote:
>> >
>> > Hi Andy.
>> >
>> >> Possibly it is the use of declare parents extends (with generics),
>> >> that is just not as common as declare parents implements.
>> >
>> > Actually, no. That was the first thing I tried, namely getting rid of
>> the interface implementation 'DefaultIdentifiable' and replacing it like
>> this:
>> >
>> >
>> > package fr.inria.zvtm.cluster;
>> >
>> > import fr.inria.zvtm.engine.Camera;
>> > import fr.inria.zvtm.engine.VirtualSpace;
>> > import fr.inria.zvtm.glyphs.Glyph;
>> > import fr.inria.zvtm.engine.portals.Portal;
>> >
>> > aspect ObjIdIntroduction {
>> > declare parents: VirtualSpace implements Identifiable;
>> > declare parents: Glyph implements Identifiable;
>> > declare parents: Camera implements Identifiable;
>> > declare parents: Portal implements Identifiable;
>> >
>> > private final ObjId Identifiable.objId = ObjIdFactory.next();
>> > private boolean Identifiable.replicated = false;
>> >
>> > public ObjId Identifiable.getObjId(){ return objId; }
>> > public boolean Identifiable.isReplicated() { return replicated; }
>> > public void Identifiable.setReplicated(boolean val) {
>> this.replicated = val; }
>> > }
>> >
>> > The resulting compilation errors were the same as before. I actually
>> tried to replicate the generics situation in a simple project, but have
>> failed to do so. Do you have a test case for it? Well, probably I should
>> just look at your Git repo and check the latest commits (if you have pushed
>> them already).
>> >
>> > Regards
>> > --
>> > Alexander Kriegisch
>> >
>> > Schillerplatz 6, 91315 Höchstadt, Germany
>> > Tel +49 (9193) 52 76, Mob +49 (176) 20 53 07 02
>> >
>> >
>> > Andy Clement schrieb am 11.04.2015 18:56:
>> >
>> >> Hey,
>> >>
>> >> Yes, Romain sent me some repo references off list so the discussion
>> ended up
>> >> continuing there. I was planning to post back here when we got to a
>> conclusion
>> >> (which we just did last night when Romain tested a 1.8.6 snapshot I
>> created
>> >> with a potential fix).
>> >>
>> >> The new method will make it into the class file proceedOnError, but of
>> course
>> >> that isn’t where the compiler is looking. The compiler is looking at
>> the raw
>> >> type binding for Glyph, and that has a super type of Object. Sometime
>> after
>> >> that raw type representation is built we apply the declare parents and
>> it
>> >> changes the super type of the generic type of Glyph to the new type
>> that
>> >> contains the missing methods. When the classfiles are written out,
>> they’ll
>> >> be based on the generic type so the correct declare parented super
>> type will be
>> >> there but for all the non generic references made in the program, they
>> will
>> >> being resolved against the raw type which does not have these methods
>> in its
>> >> hierarchy.
>> >>
>> >> I don’t quite understand why this is only coming up now, looks to have
>> been
>> >> missing for a long time. Possibly it is the use of declare parents
>> extends
>> >> (with generics), that is just not as common as declare parents
>> implements.
>> >>
>> >> The fix is simply to have a look for a raw type when patching up the
>> generic
>> >> type and fix that up too, possibly there is an issue with
>> parameterized types
>> >> too but I have no test program that shows me there is an issue (yet).
>> >>
>> >> A proceed on error without the fix would probably leave the code with
>> eclipse
>> >> exception throwing code generated at the bad method call sites that
>> would fail
>> >> at runtime when exercised. I never recommend proceedOnError.
>> >>
>> >> cheers,
>> >> Andy
>> >>
>> >>> On Apr 11, 2015, at 5:47 AM, Alexander Kriegisch <
>> alexan...@kriegisch.name>
>> >>> wrote:
>> >>>
>> >>> Sounds good, Romain, I had no idea Andy was in touch with you.
>> >>>
>> >>> BTW, I noticed that if you add
>> >>> <proceedOnError>true</proceedOnError>
>> >>> to the POM of zvtm-cluster, the build continues and the necessary
>> methods seem
>> >>> to be there in the resulting class files. Can you please test that
>> with the
>> >>> official v1.8.5 (not the fixed preview) and tell me if the software
>> actually
>> >>> does what it is supposed to? I have no idea how to test that because
>> I do not
>> >>> know ZVTM. I am just curious if this workaround to keep the build
>> going
>> >>> actually works or leaves behind inconsistently woven class files.
>> >>>
>> >>> Thanks in advance
>> >>> --
>> >>> Alexander Kriegisch
>> >>> http://scrum-master.de
>> >>>
>> >>>
>> >>> Romain Primet schrieb am 11.04.2015 14:35:
>> >>>
>> >>>> Hi Alexander,
>> >>>>
>> >>>> I got a reply from Andy off-list; looks like an issue with ITD and
>> >>>> generic types (ITD not being done on raw type). I'm sure Andy will be
>> >>>> more precise; also, he has provided me with a snapshot build of
>> aspectj
>> >>>> that builds zvtm-cluster just fine.
>> >>>>
>> >>>> Thanks a lot to you both for the debugging and help!
>> >>>>
>> >>>> Romain
>> >>>>
>> >>>> Le 11/04/2015 14:31, Alexander Kriegisch a écrit :
>> >>>>> Hi Andy.
>> >>>>>
>> >>>>> I have looked into this a little more and noticed that the build
>> within
>> >>>>> Eclipse Luna with AJDT works nicely, but fails with AspectJ Maven
>> Plugin and
>> >>>>> on the command line via ajc.bat. So this might be a clue what it
>> going wrong
>> >>>>> if you can answer one question: What does ADJT differently in
>> comparison to
>> >>>>> Ajc with regards to build order or other relevant factors?
>> >>>>>
>> >>>>> I have also noticed that if I remove the three Aspect files
>> >>>>> - GlyphCreation.aj
>> >>>>> - GlyphReplication.aj
>> >>>>> - VirtualSpaceReplication.aj
>> >>>>> from zvtm-cluster, the module compiles fine. This is because these
>> aspects
>> >>>>> rely on ObjIdIntroduction.aj being woven first as they expect the
>> introduced
>> >>>>> methods to be present in the target classes from module zvtm-core.
>> >>>>>
>> >>>>> I also tried to replicate a minimal sample with a Java project and
>> an
>> >>>>> AspectJ
>> >>>>> project having the Java project on its inpath. The AspectJ project
>> has three
>> >>>>> aspects which rely on each other's methods being present. It does
>> not show
>> >>>>> any
>> >>>>> errors during compilation from either Eclipse or command line
>> though. So
>> >>>>> probably you need to analyse the real project. To me it definitely
>> looks
>> >>>>> like
>> >>>>> a bug.
>> >>>>>
>> >>>>> Regards
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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
>> >>
>> >> _______________________________________________
>> >> 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
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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
