Community
Participate
Working Groups
Steps to reproduce: (1) Install plain Eclipse SDK (3.2.1) (2) Install AspectJ from update site (http://download.eclipse.org/tools/ajdt/32/update) (3) Create new Java project (not AJ project for the next step to work, otherwise it is impossible to verify that APT actually works). (4) Follow demo APT instructions (http://www.eclipse.org/jdt/apt/index.html), ensure that squiggles appear, that file is being generated. One step that might be missing on that page is that you might need to also add downloaded JAR file to project class path. (5) Right-click project, AspectJ Tools -> Convert to AspectJ project... At this point APT processing stops working -- you can verify this by removing/adding demo APT annotations. If default Java builder is added to the .project file (in addition to the AspectJ builder), then APT processing will work again. However it becomes impossible to edit AJ files -- they look like one big 'error' to the default Java builder. Of additional note -- I also tried the same on Eclipse 3.3M4 with AJDT 1.5.0 -- it results in the same problem -- APT stops working.
Passing over to AspectJ compiler. I suspect this is because the compiler is currently based on JDT from Eclipse 3.1.
yep
*** Bug 170476 has been marked as a duplicate of this bug. ***
Needs testing on AJDT 1.5.2 (AspectJ1.6.0m1) - as that is now Eclipse 3.3 based. That may fix it.
Note that this is an issue with the jdt-apt, not the apt. JDT-apt requires a 1.5-aware (or maybe it's even 1.6 now) execution environment. The AJDT plugins expect 1.4. So, this *might* be an AJDT problem.
For others affected by this, I came across: http://www.eclipse.org/newsportal/article.php?id=1966&group=eclipse.technology.ajdt#1966 Which notes you can work around this bug by listing both the javabuilder and ajbuilder in your .project file.
*** Bug 323454 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Which notes you can work around this bug by listing both the javabuilder and > ajbuilder in your .project file. I'm guessing that this will work in some situations, but may cause some instability in others. For example, the JavaBuilder is better at producing incremental state than the AJBuilder. If the AJbuilder fails to compile certain files due to some interaction with an aspect, the JavaBuilder may still be able to build the file (albeit without weaving it). So, the file will *look* built but it really won't be. I can think of some other problems too. Regardless, if you want to live on the edge, and be prepared to do full builds when things go haywire, it will likely work. Make sure that the JavaBuilder is the second in the .project file. As to a possible solution, it looks like JDT implements APT through the use of a CompilationParticipant. AJBuilder would need to be aware of Compilation participants and execute all the appropriate callbacks. So, it looks to me like this really is an AJDT issue. It may not be entirely difficult to implement and the AptCompilationParticipant may just work.
(In reply to comment #8) > As to a possible solution, it looks like JDT implements APT through the use of > a CompilationParticipant. AJBuilder would need to be aware of Compilation > participants and execute all the appropriate callbacks. So, it looks to me > like this really is an AJDT issue. It may not be entirely difficult to > implement and the AptCompilationParticipant may just work. If someone on AJDT is interested in working on this, I can help you get the compilationParticipant part working. Also, re the question in Comment 5: APT requires a 1.5 environment in order to run Java 5 (com.sun.mirror.apt) processors, and a 1.6 environment in order to run Java 6 (javax.annotation.processing) processors. Note that annotation processors can contribute additional Java files (which is why APT needs to use compilationParticipant rather than just being a separate builder). Presumably those files would need to be entered into the weaving process; it becomes a loop (or a recursion) rather than a linear step.
> As to a possible solution, it looks like JDT implements APT through the use of > a CompilationParticipant. AJBuilder would need to be aware of Compilation > participants and execute all the appropriate callbacks. So, it looks to me > like this really is an AJDT issue. It may not be entirely difficult to > implement and the AptCompilationParticipant may just work. That's interesting, because I previously prototyped the full solution to this following JDTs usage pattern (for Spring Roo), got it working, and never changed AJDT directly... in the end they didn't need it so I didn't finish it off.
This is becoming more important for integration with GWT.
Current status: I have something in my workspace that appears to be working for a subset of the CompilationParticipant API. It is far from being ready to commit and will not make the 2.1.1 release. When this is complete, the following methods of BuildContext will work as expected: getContents() : will get the contents of the file getFile() : will get the IFile recordDependencies(String[]) : will record a new dependency recordNewProblems(CategorizedProblem[]) : will record new problems on this compilation unit, and these problems will appear in the file The following pieces will not work: hasAnnotations() : we ignore this method and always return false recordAddedGeneratedFiles(IFile) : ignored (no-op) recordDeletedGeneratedFiles(IFiel) : ignored (no-op) On the CompilationParticipant class, the following methods will be respected: aboutToBuild(IJavaProject) : called when the build is starting buildFinished(IJavaProject) : called when the build has finished buildStarting(BuildContext[]) : this method is actually called after the build finishes and we know exactly what has been compiled. cleanStarting(IJavaProject) : called when a clean is starting isActive(IJavaProject) : used to determine which participants are active for a given project reconcile(ReconcileContext) : called after a reconcile and can register additional problems to the reconcile Note that the compiler is not run in a loop and so that files generated by a participant are not added to the build. The following methods are not respected isAnnotationProcessor() : ignored. does not process annotations processAnnotations(BuildContext[]) : ignored
This is now working as described in the previous comment and is a good enough implementation for now. If we need a more complete implementation in the future, then we will work on it then.
It seems like I have run into this bug. Which version has the fix? I am using version 2.2.0.e36x-20110908-0800 of AJDT.
What exactly is the problem that you are having? The version of AJDT that you are using has all of the most recent changes for this issue. But, the full API is has not been implemented. Most importantly, we do not run the compiler in a loop if new files are added. You may be hitting something like this that we do not support. Please be specific about what problem you are seeing.
Here is my scenario. I have my own annotation processor which generates some code and works fine in a plain Java project. When I turn this into an AspectJ project (using Configure-> Convert to AspectJ Project), my annotation processor no longer gets invoked and the generated sources from the previous run (before the conversion) also get deleted. If I disable AspectJ for that project (using AspectJ Tools-> Remove AspectJ Capability command), my annotation processor starts working again. (In reply to comment #15) > What exactly is the problem that you are having? The version of AJDT that you > are using has all of the most recent changes for this issue. But, the full API > is has not been implemented. Most importantly, we do not run the compiler in a > loop if new files are added. You may be hitting something like this that we do > not support. > > Please be specific about what problem you are seeing.
Is this a Java 5 style Annotation processor or Java 6 style? Java 6 style annotation processors are not supported. If it is Java 5 style, then there is something that we should work on here.
I am using Java 6 style annotation processor and wont be able to switch to Java 5 at this time. Are you saying that AspectJ is not supported on Java 6? Is there any workaround other than re-implementing our annotation processor using Java 5 api?
AspectJ supports Java 6. It is built on top of a Java 6 compiler. However, annotation processing has not been completely implemented.
Thanks for the prompt responses. Are there plans to support this anytime soon?
The best thing to do is to contact the aspectj-users mailing list. Describe your problem as precisely as possible. There may be a workaround for your purposes. It's not out of the question that this feature will be added in the future, but this feature is not scheduled for AspectJ 1.6.12.
The mailing lists are here: http://eclipse.org/aspectj/userlists.php
I'll comment here (as AspectJ lead). If you mean the feature discussed as https://bugs.eclipse.org/bugs/show_bug.cgi?id=252199 - it is very unlikely to get in anytime soon, I'm afraid.
(In reply to comment #8) > Regardless, if you want to live on the edge, and be prepared to do full builds > when things go haywire, it will likely work. Make sure that the JavaBuilder is > the second in the .project file. I'm using GWT Request Factory annotation processor (http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation) with Eclipse and AspectJ and the only configuration in which both aspects and APT work for me is using both java builder and aspectj builder. But what's strange, classes are woven only if I arrange builders in opposite sequence as Andrew described - java builder before aspectj builder. It seemed for me like when javac builder is second, it overrides classes generated by aspectj (but it's only my presumption). Support for java 6 style APT would be really useful because all Spring Roo generated GWT applications uses both AspectJ and RequestFactory which requires running java 6 style APT processor.
