@GenDto in a @GenEvent (or @GenDispatch) vs clean / rebuild all

[Brian Witt]

Hi, I'm having an issue where I have a @GenDto class and I'm referring
to it in a @GenEvent class. The problem arises after a clean all /
rebuild all, when the resulting Event class does not have the full
name of the Dto class (e.g. com.example.sample.TransferDto) and
instead only has the name of the class (TransferDto) and it doesn't
compile since it doesn't do an import for that class. If I then touch
the @GenEvent class to force a rebuild of just that class, the
generated code is fine (has com.example.sample.TransferDto).

For instance, if my classes are
@GenDto
public class Transfer {
}

@GenEvent
public class TransferHappened {
TransferDto transfer;
}

So after a clean all, rebuild all, the generated
TransferHappenedEvent.java will have references to
just TransferDto instead of com.example.sample.TransferDto and not
compile.

but if I regenerate just that class, it'll contain
com.example.sample.TransferDto
instead, which will compile and everything is great.

Am I doing something wrong? I'm using I'm using gwtp-
all-0.6-20110508.192419-8.jar and Eclipse and followed
http://code.google.com/p/gwt-platform/wiki/BoilerplateGeneration for
setup. I'm also seeing this not working for @GenDispatch as well as
under ant.

Thanks,
Brian

[Christoph MEIER]

Hi, I had the same issue. For now I just put the @GenDto class and the
@GenDispatch class in the same package. I know this is not ideal but
it works.

[Flori]

Hm I think the processors can't find TransferDto during a complete
recompile (probably due to the alphabetical (not exactly sure) order
of processing) and therefore a FQN is not available. If you only
compile TransferHappenedEvent, the TransferDto already exist and the
environment can determine the FQN.

Did you already try to use the FQN in your GenEvent class?

package com.mypackage.event;

@GenEvent
public class TransferHappened {
com.mypackage.dto.TransferDto transfer;
}

On May 18, 10:45 am, Christoph MEIER <meier.christoph.0...@gmail.com>
wrote:

[Brian Witt]

Yes using the FQN works! For ant and Eclipse! Strange, but for a
while there, Eclipse was refusing to generate any GenEvent,
GenDispatch, or GenDto classes at all (nothing in the .apt_generated
folder except for one random action class). Then suddenly, after
removing and adding the gwtp-all jar from the Annotation Processing
Factory Path a few times, and restarting Eclipse a few times, it
magically started working again. Weird.

Thanks again for the workaround!
Brian

[Brian Witt]

BTW I just noticed eclipse was logging errors like this one related to
the annotation processors:

(they're all NullPointerException with commonality up to
at
com.gwtplatform.dispatch.annotation.processor.GenerationHelper.close(GenerationHelper.java:
49)

which is
writer.close()
but I guess the issue is something deeper than simply writer is
null :)



eclipse.buildId=M20100909-0800
java.version=1.6.0_20
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Command-line arguments: -os linux -ws gtk -arch x86_64


Error
Wed May 18 18:20:13 PDT 2011
Exception thrown by Java annotation processor
com.gwtplatform.dispatch.annotation.processor.GenDispatchProcessor@673a5bf0

java.lang.NullPointerException
at
org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.addJava6GeneratedFile(AptCompilationParticipant.java:
272)
at
org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeProcessingEnvImpl.addNewUnit(IdeProcessingEnvImpl.java:
132)
at
org.eclipse.jdt.internal.apt.pluggable.core.filer.IdeJavaSourceOutputStream.close(IdeJavaSourceOutputStream.java:
72)
at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:319)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:148)
at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
at java.io.BufferedWriter.close(BufferedWriter.java:265)
at java.io.PrintWriter.close(PrintWriter.java:312)
at java.io.BufferedWriter.close(BufferedWriter.java:265)
at java.io.PrintWriter.close(PrintWriter.java:312)
at
com.gwtplatform.dispatch.annotation.processor.GenerationHelper.close(GenerationHelper.java:
49)
at
com.gwtplatform.dispatch.annotation.processor.GenDispatchProcessor.generateAction(GenDispatchProcessor.java:
150)
at
com.gwtplatform.dispatch.annotation.processor.GenDispatchProcessor.generateGenDispatch(GenDispatchProcessor.java:
87)
at
com.gwtplatform.dispatch.annotation.processor.GenDispatchProcessor.process(GenDispatchProcessor.java:
75)
at
org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:
139)
at
org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:
121)
at
org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:
159)
at
org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:
134)
at
org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:
809)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:
428)
at
org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:
364)
at
org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:
321)
at
org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:
301)
at
org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.buildAfterBatchBuild(IncrementalImageBuilder.java:
171)
at
org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:
66)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:
254)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:
173)
at org.eclipse.core.internal.events.BuildManager
$2.run(BuildManager.java:629)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:
172)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:
203)
at org.eclipse.core.internal.events.BuildManager
$1.run(BuildManager.java:255)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:
258)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:
220)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:
362)
at org.eclipse.core.internal.resources.Project$1.run(Project.java:545)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:
1975)
at
org.eclipse.core.internal.resources.Project.internalBuild(Project.java:
524)
at org.eclipse.core.internal.resources.Project.build(Project.java:115)
at org.eclipse.jdt.internal.ui.util.CoreUtility
$BuildJob.run(CoreUtility.java:160)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Thanks,
Brian

[Brendan Doherty]

This sounds like a bug.  

Do you have "import com.example.sample.TransferDto;" at the top of TransferHappened.java?

[Brian Witt]

Sure do.

On May 21, 3:57 pm, Brendan Doherty <bren...@propertysimplified.com>
wrote:

[dindeman]

Hello everyone.

I having a similar issue in a simpler context than Brian.
I was first using only @GenDispatch with no issue to generate all my
dispatcher's actions and results.
Then I gave it a try to replace my events and handlers with those
generated through @GenEvent.
The first couple event/handler works fine, it's generated and can be
used. So I mean it works fine with ONE @GenEvent annotated class.
But as soon as I try to generate the second couple event/handler (so
when I put in the second @GenEvent annotated class) I'm getting the
following trace upon building:

Problems occurred when invoking code from plug-in:
"org.eclipse.core.resources".

java.lang.NullPointerException
at
org.eclipse.jdt.internal.compiler.apt.model.ElementImpl.hashCode(ElementImpl.java:
110)
at java.util.HashMap.put(Unknown Source)
at java.util.HashSet.add(Unknown Source)
at
org.eclipse.jdt.internal.compiler.apt.util.ManyToMany.put(ManyToMany.java:
198)
at
org.eclipse.jdt.internal.compiler.apt.dispatch.AnnotationDiscoveryVisitor.resolveAnnotations(AnnotationDiscoveryVisitor.java:
187)
at
org.eclipse.jdt.internal.compiler.apt.dispatch.AnnotationDiscoveryVisitor.visit(AnnotationDiscoveryVisitor.java:
128)
at
org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.traverse(MethodDeclaration.java:
207)
at
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:
1290)
at
org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.traverse(CompilationUnitDeclaration.java:
679)
at
org.eclipse.jdt.internal.compiler.apt.dispatch.RoundEnvImpl.<init>(RoundEnvImpl.java:
56)
at
org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:
148)

at
org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:
134)
at
org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:
809)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:
428)
at
org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:
364)
at

org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:
178)
at
org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:
301)
at
org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:
60)

at
org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:
254)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:
173)
at org.eclipse.core.internal.events.BuildManager

$2.run(BuildManager.java:627)

at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:

170)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:
201)
at org.eclipse.core.internal.events.BuildManager
$1.run(BuildManager.java:253)

at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:

256)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:
218)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:
360)
at org.eclipse.core.internal.resources.Project$1.run(Project.java:
523)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:
1800)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:
1782)
at
org.eclipse.core.internal.resources.Project.internalBuild(Project.java:
502)
at org.eclipse.core.internal.resources.Project.build(Project.java:94)
at
org.eclipse.ui.actions.BuildAction.invokeOperation(BuildAction.java:
221)
at
org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:
162)
at org.eclipse.ui.actions.WorkspaceAction
$2.runInWorkspace(WorkspaceAction.java:483)
at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:
38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

I hope this might help getting things sorted... or maybe someone could
tell me what I'm doing wrong if anything obvious?
Regards.
Luc

[Brendan Doherty]

Hi Luc, 

Unfortunately your stacktrace doesn't help as it doesn't mention gwtplatform.  

What version of gwt-platform are you using?

How are you building your project? (maven, eclipse, ant).

Can you reply with both of the @GenEvent annotated classes?

How have you configured the annonation processor (if eclipse, please include screenshot), if maven, please include xml that you think could be useful.

Personally I'm using 0.6-SNAPSHOT, and build with both maven and eclipse with m2eclipse, and have no problems. 

Brendan

[Brendan Doherty]

Are you able to repost the full Transfer and TransferHappened classes including the package and import lines.  (Feel free to replace the first part of your packages with "com.example." if you want to keep your project partially confidential.

I'd like to try reproducing the problem, but without imports I can't be sure it's correct.

[dindeman]

Hi Brendan.

I'm using GWTP 0.6-SNAPSHOT and Eclipse (no Maven, no Ant).
Here are the snapshots of my annotations processing configuration in
Eclipse:
http://www.dropbox.com/gallery/17121913/1/Eclipse%20GWTP%20Annotations%20config?h=b0279e

I just tried again and I'm getting the build error (with the stack
trace I already pasted in my previous message) as soon as I annotate a
second class with @GenEvent.
I never had any issue with @GenDispatch and I'm not using @GenDTO yet.
My package structure is the following:

...client.events
...client.genevent
...
...shared.gendispatch

I obviously need to keep an 'events' package, since I can only
generate one event through @GenEvent all the other custom events are
still in 'events'.

Well I hope this is giving you some more hints as to what can be the
issue here.
Regards.
Luc

On May 24, 11:06 am, Brendan Doherty <bren...@propertysimplified.com>
wrote:

[Brendan Doherty]

Luc, are you able to repost the full source code classes for the @GenEvent annotated classes that are causing the problem including the package and import lines.  (Feel free to replace the first part of your packages with "com.example." if you want to keep your project partially confidential.

I'd like to try reproducing the problem, but need the source code.

Also, are you able to look in the .apt_generated directory, and see if there are any generated files?

Here are is the source code from a few of my events.  Hope it helps.

package com.example.client.events;

import com.gwtplatform.dispatch.annotation.GenEvent;

@GenEvent

public class Selection {

    public int selectionIndex;

}

---

package com.example.client.events;

import com.gwtplatform.dispatch.annotation.GenEvent;

@GenEvent

public class Loading {

    public boolean showLoading;

}

---

package com.example.client.events;

import com.gwtplatform.dispatch.annotation.GenEvent;

import com.gwtplatform.dispatch.annotation.Order;

@GenEvent

public class ContentScroll {

    @Order(1)

    public int viewportHeight;

    @Order(2)

    public int scrollHeight;

    @Order(3)

    public int scrollTop;

}

---

package com.example.client.events;

import com.gwtplatform.dispatch.annotation.GenEvent;

@GenEvent

public class ContentResize {

    public int height;

}

[Brendan Doherty]

Are you guys still have problems?  

I've committed a change to the annotation processors that produce more debug messages when generated code.   

Hopefully this will help us track down the problem.

Brendan

[dindeman]

Hi Brendan.

Well I went into some further trials and here is what I've got.
Basically I was trying to get rid of my fully hand written custom
events/handlers to switch to new ones generated through the @GenEvent
annotation. And this exercise has provided not to be straightforward
at all.

Here is how I can reproduce the issue.
Let's say I have already a custom event that I wrote myself WITHOUT
using @GenEvent (eg. 'UserLogoutEvent') and that is already in use
throughout my code. It embeds a public interface UserLogoutHandler to
give it the same shape as what would be generated through the
annotation. Moreover it sits in the package I use for the @GenEvent
annotated classes, this way no code refactoring is necessary when
switching from a manually written event/handler to a @GenEvent
generated event/handler.
So here is what I do:

1. I create the @GenEvent class UserLogout alongside with the existing
UserLogoutEvent (so both lie in the same package, as mentioned above.)
2. I build the project. At this stage I have two sets of
UserLogoutEvent/UserLogoutHandler, the manual one and the generated
one.
3. I delete the "old" event/handler to remain only with the one
generated through @GenEvent.

At that stage everything works fine, I can debug my app, my unit tests
are running fine... etc.
The problem occurs the next time I clean/build the project. When I do
that it refuses to regenerate again the events/handlers which of
course leads to all sort of errors.
Here is the error I'm then getting (basically, always the same one):
'Problems occurred when invoking code from plug-in:
"org.eclipse.core.resources".'
and the same stack trace as the one I have already pasted in my first
message.

Note that if I proceed to 3. (the deletion of the old event/handler)
BEFORE building the project with the new annotated UserLogout class, I
get the error straight upon building without even being able to
generated the event/handler classes once.

However, I can create more than one event/handler with @GenEvent as
soon as the new one I create doesn't replace an existing one. So to
that extent I was wrong in my previous message as I didn't realize yet
that the issue was coming from the replacement process. Which means
that my issue is essentially some sort of refactoring issue.

I hope this will help you understand what might be going wrong with my
project. Do you reckon the changes you've checked in would solve
anything of the above yet?

Thanks again for looking into this, it's very much appreciated.
Thankfully this is not critical as I can keep living with my old event/
handlers and use the annotation only for new ones for now!

Best regards.
Luc

On May 29, 11:31 am, Brendan Doherty <bren...@propertysimplified.com>
wrote:

[Philippe Beaudoin]

Hi Luc,

Thanks for the detailed account, I'm not the maintainer of annotation processors so I'll let these guys answer. However, it might help if you described your build process. Straight from eclipse? With ant? With maven? My guess is that problem lies in the build configuration, so any information you can provide on this might help. (Options selected in eclipse, or plugin details in Maven...)

Cheers,

   Philippe

[dindeman]

Hi Philippe, Brendan.

Ok I'm building the project with Eclipse, and no Ant, no Maven.
See the snapshots at http://www.dropbox.com/gallery/17121913/1/Eclipse%20GWTP%20Annotations%20config?h=b0279e
to visualize my build configuration.

I have pinpointed how the issue specifically arises in my own project.
What doesn't work is to attempt the processing of @GenEvent WHEN some
classes already implement the event handler that's got to be
generated.
It makes sense at first glance but in fact there really is an issue.
Here are the steps:

1. I create a @GenEvent class MyTest (with no arguments to keep it
simple.)
2. I build the project. All good here, MyTestEvent and its embedded
MyTestHandler are generated.
3. I make one of my classes to implement MyTestEvent.MyTestHandler.
4. I can run, debug... etc. All still good at this stage.
5. I rebuild the project again and there the issue arises.

It seems that it doesn't like to generate the event/handler again when
the handler is already implemented somewhere.
If I skip step 3, so if I don't make any of my classes implement the
new handler, then I can keep rebuilding the project with no problem
and get all the annotated classes to be generated over and over again.
But as soon as I implement the handler once no more flawless build
would process anymore, no more annotated classes generated... etc.

Do you think this can be linked to some build option somewhere? Maybe
is it a bug in my version of Eclipse?
Clearly it's related to my own config/environment as otherwise the
above steps would strike everyone all the time.

Thanks for supporting me through this one! I feel quite lonely... ;-)

Regards.
Luc

FYI again, the error I'm then getting on rebuild is: Problems occurred

when invoking code from plug-in: "org.eclipse.core.resources".

And the stack trace:

org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:
309)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:
341)
at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:
330)
at org.eclipse.ui.actions.GlobalBuildAction
$1.run(GlobalBuildAction.java:178)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

[Philippe Beaudoin]

I'm sorry I can't help more as everything looks good in these screen. :(  Maybe with the full project I might be able to help... In my experience, annotation processing in Eclipse is surprisingly tricky. For example, maybe you added the .apt_generated to your source folders when you shouldn't have?

Cheers,

   Philippe

[dindeman]

Hey Philippe, thanks for your reply.

Well, as I said I can live with this for now and I will keep writing
my own events/handlers manually. The boilerplate code generation works
through @GenDispatch for actions/results which is the main thing for
me at the moment, events/handlers are much less of a hassle to write.
As soon as I get time I will investigate further in the context of a
simpler/smaller project.

Btw I had a design question regarding the way events/handlers are
generated.
Why didn't you name the embedded handler's type 'Handler' ? Like

public TriggerEvent ... {
public interface Handler ... {
public void onTrigger(TriggerEvent event) {
...
}
}
...
}

instead of

public TriggerEvent ... {
public interface TriggerHandler ... {
public void onTrigger(TriggerEvent event) {
...
}
}
...
}

?

Wouldn't it be shorter/easier to simply refer to the handler as
TriggerEvent.Handler (instead of TriggerEvent.TriggerHandler) ?

Regards.
Luc

On Jun 3, 7:51 pm, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

> I'm sorry I can't help more as everything looks good in these screen. :(
>  Maybe with the full project I might be able to help... In my experience,
> annotation processing in Eclipse is surprisingly tricky. For example, maybe
> you added the .apt_generated to your source folders when you shouldn't have?
>
> Cheers,
>
>    Philippe
>
>
>
>
>
>
>
> On Fri, Jun 3, 2011 at 1:58 AM, dindeman <dinde...@googlemail.com> wrote:
> > Hi Philippe, Brendan.
>
> > Ok I'm building the project with Eclipse, and no Ant, no Maven.
> > See the snapshots at

> >http://www.dropbox.com/gallery/17121913/1/Eclipse%20GWTP%20Annotation...

[Philippe Beaudoin]

Good question. I'll let the designers of this part answer.

   Philippe

[Philippe Beaudoin]

Also, just though of a manual "fix" I do once in a while in Eclipse when annotation processors don't work. It may help you:

- Right-click on the project > properties > Java Compiler > Annotation Processing.

- Uncheck "Enable project specific settings"

- Click apply

- When prompted to rebuild, say yes

- Check "Enable project specific settings"

- Click apply

- When prompted to rebuild, say yes

Cheers,

   Philippe

[dindeman]

Upgrading from Eclipse Galieo to Eclipse Helios fixed the problem.
I'll never know what was going wrong...

On Jun 5, 9:44 pm, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

> Also, just though of a manual "fix" I do once in a while in Eclipse when
> annotation processors don't work. It may help you:
>
> - Right-click on the project > properties > Java Compiler > Annotation
> Processing.
> - Uncheck "Enable project specific settings"
> - Click apply
> - When prompted to rebuild, say yes
> - Check "Enable project specific settings"
> - Click apply
> - When prompted to rebuild, say yes
>
> Cheers,
>
>    Philippe
>
> On Sat, Jun 4, 2011 at 10:45 PM, Philippe Beaudoin <
>
>
>
>
>
>
>
> philippe.beaud...@gmail.com> wrote:
> > Good question. I'll let the designers of this part answer.
>
> >    Philippe
>

[Philippe Beaudoin]

Yeah, the plugin was not made for Galileo. I'm not an Eclipse Plugin expert, but things have obviously changed between these two releases.

   Philippe

[dindeman]

Well this was related to the annotation processing issue I had (with
@GenEvent.)
But indeed, the annotation processing as well as the plugin work fine
now that I upgraded to Helios.

On Jun 28, 1:00 pm, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

[Yurx]

It's been a year since the issue was reported and it seems like the it is still there. It is hard to tell whether it is Eclipse problem or GWTP annotation processor problem. It happens every once in several months. It gets fixed after spending an hour removing/adding libraries and jars, enabling/disabling annotation processing, cleaning/rebuilding projects, restarting eclipse, performing all sorts of crazy voodoo rituals, etc. The Eclipse log file throws NullPointerExceptions with no explicit reference to GWTP processor (see below).

!ENTRY org.eclipse.jdt.apt.core 4 1 2012-06-29 10:55:41.804
!MESSAGE Processor failure during reconcile
!STACK 0
java.lang.NullPointerException
                at org.eclipse.jst.ws.internal.annotations.core.processor.AnnotationsCoreProcessorFactory.getProcessorFor(AnnotationsCoreProcessorFactory.java:49)
                at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.dispatchToFileBasedProcessor(APTDispatchRunnable.java:648)
                at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.access$0(APTDispatchRunnable.java:626)
                at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable$ReconcileEnvCallback.run(APTDispatchRunnable.java:78)
                at org.eclipse.jdt.apt.core.internal.env.ReconcileEnv$CallbackRequestor.acceptBinding(ReconcileEnv.java:135)
                at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:925)
                at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:577)
                at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:894)
                at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:859)
                at org.eclipse.jdt.apt.core.internal.env.ReconcileEnv.openPipeline(ReconcileEnv.java:108)
                at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newReconcileEnv(AbstractCompilationEnv.java:97)
                at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.reconcile(APTDispatchRunnable.java:219)
                at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringReconcile(APTDispatchRunnable.java:167)
                at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.reconcile(AptCompilationParticipant.java:223)
                at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation$1.run(ReconcileWorkingCopyOperation.java:257)
                at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
                at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.notifyParticipants(ReconcileWorkingCopyOperation.java:244)
                at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94)
                at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
                at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
                at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1244)
                at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
                at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
                at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
                at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
                at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
                at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
                at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
                at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:104)
                at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
                at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

Am I correct guessing that there is still no knowledge of what causes it and what fixes it?