Community
Participate
Working Groups
raised as an issue on the mailing list
My .classpath entries should help here. base project is: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry excluding="**/.svn/" kind="src" path="all/src/main/java"/> <classpathentry kind="lib" path="all/lib/ide/activation.jar"/> <classpathentry kind="lib" path="all/lib/ide/crimson.jar"/> <classpathentry kind="lib" path="all/lib/ide/gnujaxp.jar"/> <classpathentry kind="lib" path="all/lib/ide/itext.jar"/> <classpathentry kind="lib" path="all/lib/ide/jbcl.jar"/> <classpathentry kind="lib" path="all/lib/ide/jcommon.jar"/> <classpathentry kind="lib" path="all/lib/ide/jfreechart.jar"/> <classpathentry kind="lib" path="all/lib/ide/junit.jar"/> <classpathentry kind="lib" path="all/lib/ide/mail.jar"/> <classpathentry kind="lib" path="all/lib/ide/mysql-connector-java.jar"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath> base-facade, which weaves it is: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="all/src/main/aspectj"/> <classpathentry excluding="**/.svn/" kind="src" path="all/src/main/java"/> <classpathentry excluding="**/.svn/" kind="src" path="all/src/test/java"/> <classpathentry kind="lib" path="all/lib/ide/collections-generic.jar"/> <classpathentry kind="lib" path="all/lib/ide/commons-beanutils.jar"/> <classpathentry kind="lib" path="all/lib/ide/commons-collections.jar"/> <classpathentry kind="lib" path="all/lib/ide/commons-lang.jar"/> <classpathentry kind="lib" path="all/lib/ide/jaxb-api.jar"/> <classpathentry kind="lib" path="all/lib/ide/jaxb-impl.jar"/> <classpathentry kind="lib" path="all/lib/ide/junit.jar"/> <classpathentry kind="lib" path="all/lib/ide/util-all.jar"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="src" path="/base"> <attributes> <attribute name="org.eclipse.ajdt.inpath" value="org.eclipse.ajdt.inpath"/> </attributes> </classpathentry> <classpathentry kind="con" path="org.eclipse.ajdt.core.ASPECTJRT_CONTAINER"/> <classpathentry kind="lib" path="/base/all/lib/ide/itext.jar"> <attributes> <attribute name="org.eclipse.ajdt.inpath" value="org.eclipse.ajdt.inpath"/> </attributes> </classpathentry> <classpathentry kind="lib" path="/base/all/lib/ide/jbcl.jar"/> <classpathentry kind="lib" path="/base/all/lib/ide/jcommon.jar"/> <classpathentry kind="output" path="bin"/> </classpath> The result after a successful build is: =========================================================================================== 17:44:53 Build kind = INCREMENTALBUILD 17:44:53 Project=base-facade, kind of build requested=Incremental AspectJ compilation 17:44:53 File: C:\Dev\cat-all-eclipse-ide\base-facade\all\src\main\aspectj\com\xx\cat\db\CacheDbQueries.aj has changed. 17:44:53 build: Examined delta - 1 changed, 0 added, and 0 deleted source files in required project base-facade 17:44:53 Setting list of classpath elements with modified contents: 17:44:53 [C:/Dev/cat-all-eclipse-ide/base-facade/all/lib/ide/collections-generic.jar, C:/Dev/cat-all-eclipse-ide/base-facade/all/lib/ide/commons-beanutils.jar, C:/Dev/cat-all-eclipse-ide/base-facade/all/lib/ide/commons-collections.jar, C:/Dev/cat-all-eclipse-ide/base-facade/all/lib/ide/commons-lang.jar, C:/Dev/cat-all-eclipse-ide/base-facade/all/lib/ide/jaxb-api.jar, C:/Dev/cat-all-eclipse-ide/base-facade/all/lib/ide/jaxb-impl.jar, C:/Dev/cat-all-eclipse-ide/base-facade/all/lib/ide/junit.jar, C:/Dev/cat-all-eclipse-ide/base-facade/all/lib/ide/util-all.jar, C:\Dev\cat-all-eclipse-ide\base\bin, C:\Dev\cat-all-eclipse-ide\base\all\lib\ide\itext.jar] 17:44:53 Timer event: 110ms: Pre compile 17:44:53 Sending the following configuration changes to the compiler: [] 17:44:53 1 source file changes since last build 17:44:53 Compiler configuration for project base-facade has been read by compiler. Resetting. 17:44:53 Configuration was [] 17:44:53 Resetting list of modified source files. Was [C:\Dev\cat-all-eclipse-ide\base-facade\all\src\main\aspectj\com\xx\cat\db\CacheDbQueries.aj] 17:44:53 Failed to find a state instance managing output location : C:\Dev\cat-all-eclipse-ide\base\bin 17:44:53 Preparing for build: planning to be an incremental build 17:44:53 Starting incremental compilation loop 1 of possibly 5 17:44:53 Timer event: 406ms: Time to first compiled message 17:44:53 Dropping back to full build 17:44:53 Preparing for build: not going to be incremental because no successful previous full build 17:44:55 Timer event: 1968ms: Time to first woven message 17:45:41 AspectJ reports build successful, build was: FULL 17:45:41 AJDE Callback: finish. Was full build: true 17:45:41 Timer event: 48357ms: Total time spent in AJDE 17:45:42 Timer event: 343ms: Refresh after build 17:45:42 Types affected during build = 2641 17:45:42 Crosscutting model sanity checked with no problems 17:45:42 Timer event: 49060ms: Total time spent in AJBuilder.build() 17:45:42 Timer event: 0ms: Post compile 17:45:42 Timer event: 15ms: Delete markers: base-facade (Finished deleting markers for base-facade) 17:45:42 Timer event: 16ms: Create markers: base-facade (Finished creating markers for base-facade)
I've checked and we only have one incremental test that involves inpath - I was surprised i didn't find a: if (project.specifiesInpath()) { forceFullBuild(); } as that is what we do for projects using outjar. Anyway, I guess I need to add one and see what happens - there might well be missing infrastructure. You are likely to get better performance actually using a linked src folder and pointing the linked src folder to the src folder in the other project rather than depending on its output. It will be compiling code twice, but you may well get incremental builds rather than full builds...
bring it onto the radar for 1.6.4
Mmm. I hadn't really thought about things being compiled twice. I take it that you mean that first, base is compiled by JDT's compiler, then it is woven with the aspects from base-facade? Linking the src seems like it would create more problems, as I'd then have to add all the base libs to my classpath, thus giving a maintenance problem.
Linked source folders would mean that it would continue to mainly exist in your pure java project and would be built there, but it would also be linked in as source to your base-facade project - and there it would be included in the source build of that project by the AspectJ compiler. Yes, you are likely to need to include the same libraries as you do when it is built in the pure java project - but don't you already find you have to do that for weaving of it from the inpath? Anyway, I was only proposing that as a temporary workaround for you to give you incremental builds since I'm not sure how long this problem will take to fix
I just created a testcase for this but as usual it doesn't really show a problem. So I created some mini projects in AJDT but it won't fail there for me either. There are two interesting lines in the output Neale attached. Firstly: 17:44:53 Dropping back to full build - this is the key thing of interest, but unfortunately the reason for the fall back to full build is not in the log *sigh*. I'd suspect it is because of a change to a file on the inpath. Secondly: 17:44:53 Failed to find a state instance managing output location : C:\Dev\cat-all-eclipse-ide\base\bin - this is because the inpath entry is from a java project, not an AJ project. If it were an AJ project then AspectJ would be maintaining a state for it that we could ask questions of. However, just because a state cannot be found does not automatically mean a full build is necessary, it just might be a slower incremental build as extra analysis is required. In a regular incremental build scenario there is just a classpath dependency between projects. If some change in a project is whitespace or just to the body of a method then any downstream project builds don't actually need to do anything. Unfortunately inpath dependencies are more complicated as whatever the change was, we need to mirror it in our project because we also have that .class file in our bin folder - and that isn't just by copying the .class file from the inpath to the bin folder of our current project. We have to pass it through the weaver which may choose to do nothing to it. From what I just wrote and knowing about the limited internal support for inpath incremental, i'm rather surprised that my testcase doesn't do a full rebuild of the downstream project when there is any kind of inpath change (which is what Neale sees). I might debug this a little to see what is going on. But I also need a system behaving like the one Neale has where it drops back to full build - on debugging that I *think* i'll just uncover that there is a lot of missing infrastructure for inpath incremental.
On the subject of that infrastructure, I wonder whether this scenario is something that is relevant to JDT, and perhaps even the general .project infrastructure, post-3.5. The scenario is that the AJ project needs to be able to interact with the JDT/PDE/faceted project. We can add to this that another project may have conflicting requirements, or it's a 'read only' project (i.e. the developer is saying "I shouldn't have to modify another project to work with it" - e.g. if I wanted to weave into your org.aspectj.ajde plugin). Both the inpath, and external src folder, fulfill the same outcome "In project base-facade, I want .class files which are the result of weaving 'base' with the .aj in base-facade, and I may, or may not want to re-export the result". We therefore have an intermediate artifact, which I'll call base-woven-with-facade (it's actually, base woven with facade's aspects) - something that on our build server we have to specifically weave when building our product. Another woven version of the same classes can be possible under an OSGi environment, e.g. base-woven-with-security.jar. I somehow suspect that Eclipse doesn't provide us all the hooks we'd need...
ok, i'm starting with a trivial inpath configuration, and just making observations. i created an AspectJ project with the jdtcore from eclipse 3.4 on the inpath. The only source file in the project is an empty class called: class C { } I've turned on Compiler, Builder and Builder/Classpath message in the event trace view. A full build: ... 11:7:27 Preparing for build: not going to be incremental because no successful previous full build 11:7:28 Timer event: 766ms: Time to first compiled message 11:7:28 Timer event: 823ms: Time to first woven message ... million of these style messages: 11:7:28 Processing progress message: Can't find eclipse resource for file with path woven class org.eclipse.jdt.core.BindingKey (from D:\org.eclipse.jdt.core_3.4.4.v_894_R34x.jar) 11:7:28 Processing progress message: Can't find eclipse resource for file with path woven class org.eclipse.jdt.core.BufferChangedEvent (from D:\org.eclipse.jdt.core_3.4.4.v_894_R34x.jar) ... 11:10:39 Timer event: 2979ms: Total time spent in AJDE 11:10:39 Timer event: 0ms: Refresh after build 11:10:39 Types affected during build = 1 11:10:39 Timer event: 2982ms: Total time spent in AJBuilder.build() 11:10:39 Timer event: 1ms: Delete markers: Inpath (Finished deleting markers for Inpath) 11:10:39 Timer event: 0ms: Create markers: Inpath (Finished creating markers for Inpath) 11:10:39 Created 0 markers in 1 files 11:10:58 Timer event: 1ms: Post compile
slight change - switching to my aj copy of the compiler jar as I have the dependencies better contained. the zillion messages are from AJDT ui: 11:44:8 Processing progress message: Can't find eclipse resource for file with path woven class org.aspectj.org.eclipse.jdt.internal.formatter.comment.IHtmlTagDelimiters (from D:\Andy\eclipse_ws\ws34\org.eclipse.jdt.core\jdtcore-for-aspectj.jar) not sure what it wants from AspectJ to make that work - presumably a jar reference style? D:\Andy\eclipse_ws\ws34\org.eclipse.jdt.core\jdtcore-for-aspectj.jar!org.aspectj.org.eclipse.jdt.internal.formatter.comment.IHtmlTagDelimiters but I guess it depends what the method workspaceRoot.getFileForLocation(resourcePath); understands.
I'm now fiddling with the single class to see what triggers a full build. whitespace change - incremental structural change (new method) - incremental promoted to aspect - full build added an advice (now it affects all types on inpath) - full build whitespace change - incremental structural change (new method) - incremental (slightly surprising) change pointcut - full build so far i'm happy with all that. I can't seem to trigger an unexpected rebuild in this scenario...
So let's switch across to an inpath dependency on a JDT project (booooo) Very simple Java Project with two classes C and D. Very simple AspectJ project with aspect A applying advice to methods in C and D. whitespace change to A - incremental build (whoa, surprised me) structural change to A (new method) - incremental build whitespace change to C (in the java project) - incremental build structural change to C (in the java project) - incremental build Some of those latter ones surprise me (and I wrote the code...) - but I've stepped through with the debugger and it really is that smart. So why do I not see anything like Neale sees? right now, i can't find an inpath incremental bug in these simple scenarios, hmm.
i went back to the mailing list post to see what Neale was originally reporting (because I'm a fool and didn't include it in my initial comment). it seems it was making a small change to an advice body. I've just tried that in my simple setup and it works fine. (incremental build). I suppose I need to see what happens on a larger project - maybe i can trigger a problem there.
ok, not failing for me on a larger project either. the only way i can trigger a full build is by making a change to the body of an around advice - which, as we know because of inlining, will always trigger a full build. hmm
I'm updating the messages to describe why builds are happening. I have hit somewhere that makes a rather arbitrary decision: if (isTypeWeReferTo(classFile)) { if (affectedFiles.size() > MAX_AFFECTED_FILES_BEFORE_FULL_BUILD) return CLASS_FILE_CHANGED_THAT_NEEDS_FULL_BUILD; } Which says if we see changes in something and more than 30 (thats what MAX* is set to) other files depend on it then lets just give up and full build. dont ask where 30 came from (was it in some snippet of JDT code we copied a long long time ago?) Because there is no diagnostic message around that check, you can't tell if that is the reason it drops back to a full build. I'm going to remove the check (so we just always try and incremental build) - check how everything goes and get some feedback from Neale with that change in a dev build. This check may be the reason we always have trouble recreating problems locally - we don't create projects big enough.
updated incremental diagnostics. It will now provide more/better info in AJDT event trace. Also put in a change to always try for an incremental build regardless of number of files touched - let's see if that helps.
waiting on an AJDT dev build that includes latest changes before doing any more with this.
Must've made a fair difference, as I'm happily working with inpath, and not noticing the builds when I save changes in my JDT project. :D <- me
Neale - are you actually getting any builds when you save your JDT project contents? For anything you do, there should be a build of the downstream AspectJ project and the updated version of whatever you saved in your JDT project should be woven and placed in the bin folder of that AspectJ project. Can you confirm (through the event trace view) that you actually see something happening?
my rudimentary test under bug 271265 showed that changing a file in a project on the inpath of an AspectJ project is not noticed by the subsequent build of that AspectJ project, so the output folder of that AJ project will not reflect the change made in the inpath project.
(In reply to comment #18) > Neale - are you actually getting any builds when you save your JDT project > contents? For anything you do, there should be a build of the downstream > AspectJ project and the updated version of whatever you saved in your JDT > project should be woven and placed in the bin folder of that AspectJ project. > > Can you confirm (through the event trace view) that you actually see something > happening? > Yes. I certainly didn't notice any problems, considering I was making changes, and running to test those changes, and the launched classes were correct. I had my eye on AJDT, and things looked fine. From memory (not at work now), the message said something like: AjState(base-facade) doesn't depend on any affected files. So, the JDT build of base, had trigged a relevant auto build of base-facade.
> I had my eye on AJDT, and things looked fine. From memory (not at work now), > the message said something like: > AjState(base-facade) doesn't depend on any affected files. So, the JDT build > of base, had trigged a relevant auto build of base-facade. I would expect a build of base-facade to trigger - but I'm surprised if it was successfully picking up a change you made to base, weaving it, and putting it in the base-facade output folder.
(In reply to comment #21) > I would expect a build of base-facade to trigger - but I'm surprised if it was > successfully picking up a change you made to base, weaving it, and putting it > in the base-facade output folder. > I've just made a change watching both bin folders, and things seem to be working fine. I changed something that does get woven, and I see the .class in base updated, and 4 in base-facade (3 ClassName$AjcClosureN.class + plus the woven class - which has grown from 9k to 13k).
Here's a log of what happened... 9:56:46 =========================================================================================== 9:56:46 Build kind = AUTOBUILD 9:56:46 Project=base-facade, kind of build requested=Incremental AspectJ compilation 9:56:46 Timer event: 0ms: Flush included source file cache 9:56:46 Timer event: 0ms: Check delta 9:56:46 Timer event: 0ms: Looking for and marking configuration changes in base-facade 9:56:46 Configuration changes found: false 9:56:46 build: Examined delta - no source file or classpath changes for project base-facade 9:56:46 Timer event: 0ms: Looking for and marking configuration changes in base-facade 9:56:46 Configuration changes found: false 9:56:46 File: C:\Dev\cat-all-eclipse-inpath\base\all\src\main\java\ClassWithJoinpoints.java has changed. 9:56:46 but, we don't have any state yet, so not recording the change. 9:56:46 build: Examined delta - 1 changed, 0 added, and 0 deleted source files in required project base 9:56:46 Timer event: 0ms: Looking for and marking configuration changes in base 9:56:46 Configuration changes found: true 9:56:46 Timer event: 0ms: Look for source/resource changes 9:56:46 Setting list of classpath elements with modified contents: 9:56:46 [C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/collections-generic.jar, C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/commons-beanutils.jar, C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/commons-collections.jar, C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/commons-lang.jar, C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/jaxb-api.jar, C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/jaxb-impl.jar, C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/junit.jar, C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/proteus-util-all.jar, C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/commons-io.jar, C:/Dev/cat-all-eclipse-inpath/base/bin, C:/Dev/cat-all-eclipse-inpath/base/all/lib/ide/itext.jar, C:/Dev/cat-all-eclipse-inpath/base/all/lib/ide/jbcl.jar, C:/Dev/cat-all-eclipse-inpath/base/all/lib/ide/jcommon.jar, C:\Dev\cat-all-eclipse-inpath\base\bin, C:\Dev\cat-all-eclipse-inpath\base\all\lib\ide\itext.jar] 9:56:46 Classpath = C:\Dev\cat-all-eclipse-inpath\base-facade\bin;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/collections-generic.jar;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/commons-beanutils.jar;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/commons-collections.jar;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/commons-lang.jar;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/jaxb-api.jar;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/jaxb-impl.jar;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/junit.jar;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/proteus-util-all.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/resources.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/rt.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/jsse.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/jce.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/charsets.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/ext/dnsns.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/ext/localedata.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/ext/sunjce_provider.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/ext/sunmscapi.jar;C:/Program Files/Java/jdk1.6.0_11/jre/lib/ext/sunpkcs11.jar;C:\Dev\cat-all-eclipse-inpath\base\bin;C:/apps/eclipse/plugins/org.aspectj.runtime_1.6.5.20090406084900/aspectjrt.jar;C:/Dev/cat-all-eclipse-inpath/base/all/lib/ide/itext.jar;C:/Dev/cat-all-eclipse-inpath/base/all/lib/ide/jbcl.jar;C:/Dev/cat-all-eclipse-inpath/base/all/lib/ide/jcommon.jar;C:/Dev/cat-all-eclipse-inpath/base-facade/all/lib/ide/commons-io.jar; 9:56:46 Timer event: 0ms: Pre compile 9:56:46 Sending the following configuration changes to the compiler: [] 9:56:46 0 source file changes since last build 9:56:46 Compiler configuration for project base-facade has been read by compiler. Resetting. 9:56:46 Configuration was [] 9:56:46 Resetting list of modified source files. Was [] 9:56:46 ClassFileChangeChecking: failed to find a state instance managing output location : C:\Dev\cat-all-eclipse-inpath\base\bin 9:56:46 Timer event: 0ms: OutputLocationManager: binary folder to declaring project map creation: P/base-facade 9:56:46 AjState(base-facade): type ClassWithJoinpoints is not depended upon by this state 9:56:46 ClassFileChangeChecking: failed to find a state instance managing output location : C:\Dev\cat-all-eclipse-inpath\base\bin 9:56:46 AjState(base-facade): type ClassWithJoinpoints is not depended upon by this state 9:56:46 Preparing for build: planning to be an incremental build 9:56:47 Examining whether any other files now need compilation based on just compiling: '{}' 9:56:47 Starting incremental compilation loop 1 of possibly 5 9:56:47 AJC: compiling source files 9:56:47 addSourcelineTask message=Join point 'field-get(java.util.Vector ParentClass.fQuestions)' in Type 'ClassWithJoinpoints' (DI_M_Anorexia.java:320) advised by around advice from 'com.xxx.cat.db.OptimisePatientSearch' (OptimisePatientSearch.aj:96) 9:56:47 addSourcelineTask message=Join point 'field-get(java.util.Vector ParentClass.fQuestions)' in Type 'ClassWithJoinpoints' (DI_M_Anorexia.java:320) advised by around advice from 'com.xxx.cat.db.OptimisePatientSearch' (OptimisePatientSearch.aj:96) 9:56:47 addSourcelineTask message=Join point 'field-get(java.util.Vector ParentClass.fQuestions)' in Type 'ClassWithJoinpoints' (DI_M_Anorexia.java:322) advised by around advice from 'com.xxx.cat.db.OptimisePatientSearch' (OptimisePatientSearch.aj:96) 9:56:47 Timer event: 531ms: Time to first woven message 9:56:47 AJC: woven class ClassWithJoinpoints (from C:\Dev\cat-all-eclipse-inpath\base\bin\ClassWithJoinpoints.class) 9:56:47 AJC: woven class ClassWithJoinpoints$AjcClosure1 (from C:\Dev\cat-all-eclipse-inpath\base\bin\ClassWithJoinpoints.class) 9:56:47 AJC: woven class ClassWithJoinpoints$AjcClosure3 (from C:\Dev\cat-all-eclipse-inpath\base\bin\ClassWithJoinpoints.class) 9:56:47 AJC: woven class ClassWithJoinpoints$AjcClosure5 (from C:\Dev\cat-all-eclipse-inpath\base\bin\ClassWithJoinpoints.class) 9:56:47 addSourcelineTask message=advice defined in com.xxx.cat.db.ReplaceLogonDialog has not been applied [Xlint:adviceDidNotMatch] file=C:\Dev\cat-all-eclipse-inpath\base-facade\all\src\main\aspectj\com\xxx\cat\db\ReplaceLogonDialog.aj line=71 9:56:47 addSourcelineTask message=advice defined in com.xxx.cat.db.ReplaceLogonDialog has not been applied [Xlint:adviceDidNotMatch] file=C:\Dev\cat-all-eclipse-inpath\base-facade\all\src\main\aspectj\com\xxx\cat\db\ReplaceLogonDialog.aj line=59 9:56:47 addSourcelineTask message=advice defined in com.xxx.cat.db.ReplaceLogonDialog has not been applied [Xlint:adviceDidNotMatch] file=C:\Dev\cat-all-eclipse-inpath\base-facade\all\src\main\aspectj\com\xxx\cat\db\ReplaceLogonDialog.aj line=30 9:56:47 AspectJ reports build successful, build was: INCREMENTAL 9:56:47 AJDE Callback: finish. Was full build: false 9:56:47 Timer event: 531ms: Total time spent in AJDE 9:56:47 Timer event: 0ms: Refresh after build 9:56:47 Types affected during build = 1 9:56:47 Not adding marker for problem because it's against a resource which is not in the list of affected resources provided by the compiler. Resource=L/base-facade/all/src/main/aspectj/com/xxx/cat/db/ReplaceLogonDialog.aj Problem message=advice defined in com.xxx.cat.db.ReplaceLogonDialog has not been applied [Xlint:adviceDidNotMatch] line=71 9:56:47 Not adding marker for problem because it's against a resource which is not in the list of affected resources provided by the compiler. Resource=L/base-facade/all/src/main/aspectj/com/xxx/cat/db/ReplaceLogonDialog.aj Problem message=advice defined in com.xxx.cat.db.ReplaceLogonDialog has not been applied [Xlint:adviceDidNotMatch] line=59 9:56:47 Not adding marker for problem because it's against a resource which is not in the list of affected resources provided by the compiler. Resource=L/base-facade/all/src/main/aspectj/com/xxx/cat/db/ReplaceLogonDialog.aj Problem message=advice defined in com.xxx.cat.db.ReplaceLogonDialog has not been applied [Xlint:adviceDidNotMatch] line=30 9:56:47 Timer event: 531ms: Total time spent in AJBuilder.build() 9:56:47 Timer event: 0ms: Update visualizer, xref, advice listeners for (separate thread): base-facade
interesting - thanks for adding that log.
unsetting the target field which is currently set for something already released
