Some UI options to make m2e-apt more effective about m2e-apt HOT 9 OPEN

Wei Cai, these look like interesting ideas.

1. we could try to add a warning marker when maven-processor-plugin is detected and -proc:none is missing. Quick fix could propose to add the missing -proc:none configuration to the pom.xml

2. Why not, the preference could be set either via pom.xml property or project/workspace preference.

3. I'm not quite sure running that part of the build won't bite us at some point like causing an infinite build loop. I'm not a JDT expert. I'd appreciate if @ifedorenko could give us his opinion

I'd be happy to review separate pull requests so we can keep the discussion focused on each problem

from m2e-apt.

I have alternative compiler plugin implementation that has proc:none by default ;-)

I am not familiar with maven-processor-plugin, but most likely you don't want to run it inside IDE, especially during incremental build.

The whole annotation processing design seems quite broken to me. Really bad mixture of different concerns that is hard to map into IDE and build workflows.

from m2e-apt.

Hi Fred,

1. For certain project, if maven-processor-plugin is defined, maven-compiler plugin is already ignored. See MavenCompilerJdtAptDelegate#isIgnored. Not sure if you mean if maven-processor-plugin is defined in any one project in workspace, we should create warning marker for missing "-proc:none"?

We have a very low level library referenced by almost all projects in workspace, and the library contains annotation processors. We have only one project defines maven-processor-plugin(let's name it "A"), while all other projects inherited a maven-compiler-plugin with no "-proc:none". We wish only project "A" get apt enabled, however almost all projects have apt enabled.

That's why I bring out a workspace preference option, I was thinking of users will either use processor-plugin or use compiler-plugin within workspace, they should not mix together.

Options in preference page could look like:
Enable apt processing for plugins:
a. maven-processor-plugin
b. maven-compiler-plugin

2. agreed.

3. I think JDT will not run into a build loop.
   Suppose project A has apt enabled, and B, C depends on A.
   Eclipse will first build A, maven builder then starts to run plugins one by one , and schedule a job when comes to processor-plugin. m2e then refresh resources without waiting the job to complete. Java Builder starts to build A after receiving resource change event, project B & C gets built, here A, B, C could have build errors as sources are not generated yet. When the processor-plugin Job is done, it refreshes the resource again, Java Builder starts to build A again, then B&C...
   As the java builder requires workspace lock, and resource change event broadcast also requires workspace lock, so java builder will run in serial mode. The only issue is A, B, C get built for second times, but it is really quick for the second time.

from m2e-apt.

1. Does #26 help? You can set a common strategy in a parent pom and override it in specific modules

2. I'd like to be sure that when the processor-plugin job is done, it won't trigger a new maven build

from m2e-apt.

Thanks for your comments.

1. Yes #26 should help, or we can have alternative compiler plugin implementation that has proc:none by default, however there is education cost for this solution, user may be not aware of the maven-compiler-plugin or apt is default disabled. I'm thinking of providing a UI option in preference page or create a warning marker is more user-friendly.

I'm also wondering why proc:none is the flag to determine enable apt or not, usually maven-compiler-plugin won't have this particular argument, so maven-compiler-plugin is get enabled silently for most projects which is probably not user's purpose. Shall we bring a new argument, like only if apt.enabled is configured in maven-compiler-plugin, m2e-apt will then start to work. User should enable this configuration if they wish to use apt. Default enabling apt for compiler plugin is a real performance killer for big projects.

3. No, it won't trigger a new maven build from my experiment. The resources generated by processor-plugin are java files, refreshing java files will trigger java builder only.

from m2e-apt.

concerning topic 2) with the proposed reconcile option ...

Is there already a full solution for this request implemented in any new version of the me2-apt plugin? Or is there a pull request existing already?
Moreover I ask myself if a change to the maven-compiler-plugin itself would be necessary here, in order to configure it through the pom.xml of a special project where apt should run. like a new parameter calling reconcileEnabled or enableTypeGenerationInEditor or anything like that (similar to properties like "generatedSourcesDirectory" aso.).
Because we are also searching for this feature for a long time now. The only thing I found out is, that the Eclipse metadata setting for the project is calling org.eclipse.jdt.apt.reconcileEnabled=false, but unfortunately it seems there is no possibility currently to configure this in the pom.xml at all.

The approach to disable it on default when applying the configurations automatically from the pom.xm through the m2e-apt connector, like caiwei-ebay mentioned, would also be ok for us.

from m2e-apt.

PR #31 has been applied and m2e-apt 1.2.0-SNAPSHOT is available from http://download.jboss.org/jbosstools/builds/staging/m2e-apt/all/repo/

Adding <m2e.apt.processDuringReconcile>false<m2e.apt.processDuringReconcile> will disable processing during the reconcile phase.

from m2e-apt.

works fine, thx

from m2e-apt.

m2e-apt's code is now included in https://github.com/eclipse-m2e/m2e-core , please consider reporting issue to https://github.com/eclipse-m2e/m2e-core/issues if it's still relevant.

from m2e-apt.