Bugzilla – Full Text Bug Listing
| Summary: | [patch] Support annotations processing | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Igor Fedorenko <igor> | ||||||||||
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | aliaksei.lahachou, benjamin.jung, cpjunk, eric.dalquist, fbricon, gonne, gregory.amerson, hello, hwellmann.de, iloncar.ml, joerg.schoenfisch, karl, lorenzb, manderse, meken, michael, paul.mcguire, rdayal, rjrjr, robert.munteanu, sslavic, tuomas.kiviaho, zregvart+eclipse | ||||||||||
| Version: | unspecified | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 380147 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Igor Fedorenko
Here is my use case which currently doesn't work well.
I'm using m2eclipse 0.12.1 and maven-compiler plugin 2.3.2.
Configuration is like [1]. m2eclipse gets confused with this config,
and configures eclipse so that src/main/java is source directory, but
it includes only **/model/core/*.java sources and not sources from any
other directory/package under src/main/java. Changing the order of
executions doesn't help either, module classpath would still contain
[2].
Am I doing something wrong here?
Regards,
Stevo.
[1] maven-compiler-plugin configuration
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
<includes>
<include>**/*.java</include>
</includes>
</configuration>
</execution>
<execution>
<id>run-annotation-processors-only</id>
<phase>generate-sources</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<compilerArgument>-proc:only</compilerArgument>
<compilerArguments>
<processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor>
</compilerArguments>
<includes>
<include>**/model/core/*.java</include>
</includes>
<generatedSourcesDirectory>${project.build.directory}/generated-sources/annotations</generatedSourcesDirectory>
</configuration>
</execution>
</executions>
</plugin>
[2] .classpath entries
<classpathentry including="**/model/core/*.java" kind="src"
output="target/classes" path="src/main/java"/>
<classpathentry including="**/model/core/*.java" kind="src"
output="target/classes" path="target/generated-sources/annotations"/>
Created attachment 192603 [details]
org.maven.ide.eclipse.apt.zip
I'm attaching an Eclipse PDE project that contains a new "AptProjectConfigurator" AbstractProjectConfigurator implementation. This implementation is against m2e version 0.12.1.20110112-1712. Please see the AptProjectConfigurator class' JavaDoc for a description of exactly what it's doing.
As this is essentially a project configurator for the maven-compiler-plugin and Eclipse's standard APT framework, I would recommend including this in m2e-core, rather than leaving it as a separate plugin. Annotation processing is now a standard part of the JDK (as of Java 6) and Eclipse.
Please note that the attached patch has a bug: the generated annotation source folder created when configuring APT will be removed from the Eclipse project classpath by the JavaProjectConfigurator if that happens to run after the AptProjectConfigurator. To resolve this, AptProjectConfigurator will also need to implement IJavaProjectConfigurator. However, a bug in 0.12.x's GenericJavaProjectConfigurator will prevent the AptProjectConfigurator.configureRawClasspath(...) method from being run. I'm going to have to rework this to apply to 0.13.x and resubmit the patch. As an FYI , this will almost certainly be over 250 lines of code (probably 400-500).. I am generally okay to include annotations processing in m2e core, either as part of m2e.jdt or as a separate bundle, provided that it 1. only introduces optional dependencies, i.e. projects that do not use annotations processing will continue to work without org.eclipse.jdt.apt.core installed 2. does not significantly affect performance and memory footprint for projects that do not use annotations processing 3. comes with reasonably good unit and/or integration test coverage Personally, I prefer to keep annotations processing separate from m2e.jdt because this would match the split between jdt.core and jdt.apt.core. Also, we require patches in git-format-patch format, so we provide proper code attribution. "main" m2e git repository is http://git.eclipse.org/c/m2e/m2e-core.git/ "test" repository is https://github.com/sonatype/m2e-core-tests Created attachment 193301 [details] bug335036-karlmdavis-2011-04-14-1403.patch This patch adds a new org.eclipse.m2e.jdt.apt bundle/project to m2e-core. This bundle will configure the Eclipse JDT-APT settings for Java projects in a way that mirrors as closely as possible the annotation processing performed by recent versions of the maven-compiler-plugin. Please see the AptProjectConfigurator JavaDoc for more information. I've created a pull request against m2e-core-tests that contains the integration tests for the new code in my patch: https://github.com/sonatype/m2e-core-tests/pull/2 Few comments/concerns * This patch breaks few existing unit tests (see list below). Some of the failure appear to be benign (i.e. additional project configurator became available), others appear to suggest the jdt.apt configurator introduces additional dependencies even for projects that do not use apt (non of existing test projects use apt, as far as I know). I think the new configuration should only affect projects that use apt and have no impact on all other projects. * Do you see this installed as of m2e.feature or as separate feature? I am slightly leaning towards separate, optional feature but don't have too strong opinion. We were planning to setup "m2e-extras" git repository at eclipse as a place to collect optional project configurators, so this may be a good first entry. * You do not need "bail if o.e.jdt.apt not available" logic in MavenJdtAptPlugin.start. It is possible to have non-optional dependency on o.e.jdt.apt in o.e.m2e.jdt.apt bundle manifest, yet tell p2 to install this bundle regardless if o.e.jdt.apt is present or not. This is how we install o.e.m2e.usagedata bundle for example. * please add eclipse copyright headers and notices as explained in http://wiki.eclipse.org/Development_Resources/Initial_Contribution > I think the new configuration should only affect projects that use apt and have no impact on all other projects.
That's tricky:
There's no way to tell from POM or code analysis which projects are "using" APT and which aren't. The maven-compiler-plugin runs any and all annotation processors available in the classpath by default, i.e. if you happen to have a dependency with an annotation processor in it, that processor will be run. I believe users can customize that by altering the plugin's configuration, but by default a "discover and run everything" approach is taken.
I've tried to take the same approach with this plugin: always configure and run APT. This could be improved a bit:
A. Search the JAR dependencies to discover if any have annotation processors and only configure APT if numProcessors >= 1. This would be a moderate improvement, and is probably worth doing but could be deferred as an enhancement for later.
B. Honor the maven-compiler-plugin's annotationProcessors property (if set) to only run the specified processors. I'd imagine most don't configure that property, though, and this would only improve the experience for the small percentage that do.
C. Have a per-project m2eclipse "flag" that allows users to enable/disable automagical APT configuration by m2eclipse, similar to the current Enable/Disable Workspace Resolution option. This is probably the best solution but has a few drawbacks:
* If enabled by default, it doesn't really address your "only affect projects that use apt" concern.
* If disabled by default, projects that require APT-generated code will have compile errors by default. This defeats one of m2eclipse's main benefits: that projects using it "just work" in Eclipse.
* I'd imagine you are keen to minimize the number of such toggles in the m2eclipse UI.
Barring any other & better ideas, I'd recommend option C and having APT enabled by default. This gives folks a way to disable it if they don't want it and won't lead to hard-to-diagnose compile errors on import for folks working with projects that require it.
Thoughts?
> It is possible to have non-optional dependency on o.e.jdt.apt in o.e.m2e.jdt.apt bundle manifest, yet tell p2 to install this bundle regardless if o.e.jdt.apt is present or not.
I'm afraid I don't understand. Looking at org.eclipse.m2e.usagedata/META-INF/MANIFEST.MF, I see that the org.eclipse.epp.usagedata.gathering bundle requirement _is_ set as optional.
I believe "option C with apt enabled" is too intrusive to be part of standard m2e installation, but probably is okay for an optional extension the user will have to install explicitly, from m2e marketplace for example. (In reply to comment #9) > > It is possible to have non-optional dependency on o.e.jdt.apt in o.e.m2e.jdt.apt bundle manifest, yet tell p2 to install this bundle regardless if o.e.jdt.apt is present or not. > > I'm afraid I don't understand. Looking at > org.eclipse.m2e.usagedata/META-INF/MANIFEST.MF, I see that the > org.eclipse.epp.usagedata.gathering bundle requirement _is_ set as optional. this was a bug, fixed now, also added some explanation to commit log message http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=bcd19b98250f7a5c31fde708931c46949744e53d Hi, using Karl's patch, I think I made some good progress having a working annotation configurator. I only made a few changes : * detect the presence of Annotation Processor in the classpath in order to enable APT support * reverted the order in which the artifacts files are sent to the AP Factory * trigger a clean build when APT is enabled * temporarily commented out the marker handling, cause it's not behaving properly Still need to add some test cases but the plugin I think we can add the plugin to the m2e-extras github repo. Are you ok to rename the plugin/packages to org.sonatype.m2e.jdt.apt ? Igor, do you plan to add it to m2e-extras github repo or a new one? >
> Igor, do you plan to add it to m2e-extras github repo or a new one?
I have not seen updated patch yet, so can't tell anything specific. We do need signed CLA from all contributors before we accept code in sonatype github repositories.
(In reply to comment #12) > * detect the presence of Annotation Processor in the classpath in order to > enable APT support Whoops, I just finished up an enhancement to do this myself today. I'd noticed the marker problems myself-- haven't looked at them yet. Triggering a build is an excellent suggestion as well. (In reply to comment #12) > * reverted the order in which the artifacts files are sent to the AP Factory What was the reason for this change? I'll be attaching a patch once I've got the marker stuff fixed up. > (In reply to comment #12) > > * reverted the order in which the artifacts files are sent to the AP Factory > > What was the reason for this change? factoryPath.addExternalJar adds the factory at the top of the list, thus reversing the classpath order defined in the pom. It causes a build issue for the infinispan-core project for instance, where a dummy class from the jboss-logging-spi gets first in line, whereas a CLI build puts the real implementation first. Also you need to exclude some artifacts from the list or you'll get some errors in the APT builder : for(Artifact artifact : artifactsInReverseOrder) { if(!"pom".equals(artifact.getType()) && artifact.isResolved()) { File artifactJarFile = artifact.getFile(); if (artifactJarFile.isFile() && artifactJarFile.canRead()) { factoryPath.addExternalJar(artifactJarFile); } } } To test your plugin, I suggest you build https://github.com/hibernate/hibernate-search and https://github.com/infinispan/infinispan/tree/master/core Finally, don't forget to send your signed Sonatype CLA (http://m2eclipse.sonatype.org/getting-involved.html), or else ... (In reply to comment #15) > Also you need to exclude some artifacts from the list or you'll get some errors > in the APT builder : > > for(Artifact artifact : artifactsInReverseOrder) { > if(!"pom".equals(artifact.getType()) && artifact.isResolved()) { > File artifactJarFile = artifact.getFile(); > if (artifactJarFile.isFile() && artifactJarFile.canRead()) { > factoryPath.addExternalJar(artifactJarFile); > } > } > } Where are you getting your artifactsInReverseOrder List from? MavenProject.getArtifacts() returns a Set, which are unordered. Additionally, I was already excluding non-JAR artifacts. You also should exclude non-compile-scoped artifacts, which the last patch does. I'm curious why you have the check for artifactJarFile.isFile()-- does Artifact.getFile() ever return a directory if Artifact.getType().equals("jar")? - Actual artifact set implementation is a LinkedHashSet, so I create an ArrayList with it. Indeed it must be filtered with a SCOPE_COMPILE - artifactJarFile.getFile() returns the target/classes directory for workspace project dependencies, the Apt builder doesn't like it. Created attachment 199626 [details] bug335036-karlmdavis-2011-07-13-1530.patch Updated the patch to implement comment #8's option A: only enable APT for projects with an annotation processor in their classpath. Also: 1. Disabled the "update configuration" markers, as the mavenProjectChanged(...) event seems to be getting fired at unexpected times. This leads to the warnings being more or less permanent. 2. Set the org.eclipse.jdt.apt.core dependency to non-optional. Did not set things to do a full build as Fred Bricon said his patch will/does. Sounds like a good idea, though-- I'd love to see a patch for it. Igor: I haven't checked but I'd be surprised if you still have unit tests failing because of this patch. Let me know. Karl, I just had a real quick look at your patch. * You should not use artifact.getType() to test if it's a jar, but artifact.getArtifactHandler().getExtension() instead; * to get the pomfile, just do mavenProjectFacade.getPom() * to trigger a full build, after setting the factorypath, call eclipseProject.build(IncrementalProjectBuilder.FULL_BUILD, monitor); * Don't call Artifact.SCOPE_COMPILE.equals(scope) but create a filter outside the loop : ScopeArtifactFilter filter = new ScopeArtifactFilter(Artifact.SCOPE_COMPILE) and then test if filter.include(artifact); Also, if a file hasn't changed in the local repo, then there's no need to open it on subsequent searches to see if it contains APs. Caching results might be a good idea here. (In reply to comment #19) > * to trigger a full build, after setting the factorypath, call > eclipseProject.build(IncrementalProjectBuilder.FULL_BUILD, monitor); This ^^^ synchronously runs the full build and almost certainly will lead to bad side effects if invoked from a project configurator. (In reply to comment #21) > This ^^^ synchronously runs the full build and almost certainly will lead to > bad side effects if invoked from a project configurator. Right. So how do you call an async job AFTER all the configurators have run? The patch does not apply cleanly on current master, please rebase. jdt.apt bundle still has 0.13.0 version, please update to 1.0.100 to match the rest of m2e. AptProjectConfiguratorTest.testAgainstArtifactExclusions fails and so do few existing integration tests. Couldn't we just separate it from m2e-core and put it into extras? I see 2 reasons for this : - it could get released faster than the next m2e - we'll most probably have to deal with org.bsc.maven:maven-processor-plugin one way or another, either by reading its configuration to configure Eclipse APT or telling m2e to ignore it in a pluginExecutionFilter. Either way that's not m2e-core's responsibility to do it. Works for me. (In reply to comment #19) > Karl, I just had a real quick look at your patch. > > * You should not use artifact.getType() to test if it's a jar, but > artifact.getArtifactHandler().getExtension() instead; Any particular reason to include non-JAR-typed artifacts that actually happen to be JARs? > * to get the pomfile, just do mavenProjectFacade.getPom() Yeah, that's what I do in the findPomResource(...) method. Why do you mention it? (In reply to comment #23) > The patch does not apply cleanly on current master, please rebase. Odd: I'd last merged from master on Friday or Monday. What are the chances this is due to me merging from master during development rather than rebasing? If that's the problem, I'm not familiar enough with git to know how to recover-- any suggestions? > jdt.apt bundle still has 0.13.0 version, please update to 1.0.100 to match the > rest of m2e. Apologies: thought I'd caught all of that. > AptProjectConfiguratorTest.testAgainstArtifactExclusions fails and so do few > existing integration tests. That's quite odd. Pardon the expression, but: "it works for me." Perhaps it's due to the patch conflicts. I'll try to investigate. (In reply to comment #24) > Couldn't we just separate it from m2e-core and put it into extras? I see 2 > reasons for this : > - it could get released faster than the next m2e > - we'll most probably have to deal with org.bsc.maven:maven-processor-plugin > one way or another, either by reading its configuration to configure Eclipse > APT or telling m2e to ignore it in a pluginExecutionFilter. Either way that's > not m2e-core's responsibility to do it. Fine by me, though it's unfortunate that the project importer won't be able to detect when this configurator is required. Any thoughts on how to mitigate that for users? (In reply to comment #23) > AptProjectConfiguratorTest.testAgainstArtifactExclusions fails and so do few > existing integration tests. Aside from testAgainstArtifactExclusions, could you please specify which tests fail? Not all the tests are passing on my box (even from master) and I want to ensure I'm not missing the ones you're concerned with in the noise. (In reply to comment #27) > (In reply to comment #23) > > AptProjectConfiguratorTest.testAgainstArtifactExclusions fails and so do few > > existing integration tests. > > Aside from testAgainstArtifactExclusions, could you please specify which tests > fail? Not all the tests are passing on my box (even from master) and I want to > ensure I'm not missing the ones you're concerned with in the noise. Can you attach rebased patch that cleanly applies to current master? I don't want you debug my local merge problems ;-) Created attachment 199751 [details] bug335036-karlmdavis-2011-07-15-0743.patch Attached a new (rebased) patch that takes care of the following suggestions: * Fixed Bundle-Version. * Switched to using a ScopeArtifactFilter I've also updated https://github.com/sonatype/m2e-core-tests/pull/2 Okay, that's odd: The new APT tests are now failing for me. Looking into it... Nevermind, just had my workspace configured wrong: my APT tests are passing. I've tried running org.eclipse.m2e.tests, and notice the following test failure that seems likely related to the APT plugin: LifecycleMappingTest.testDefaultJarLifecycleMapping(). I can get this test passing by editing line 259 to expect 2 configurators instead of 1. Is that a reasonable fix? If needed, I can also fix line 260 to not be order-dependent. There are also a number of other test failures in org.eclipse.m2e.tests, but these seem unrelated to APT and also appear if I run the tests off of master. I can't run org.eclipse.m2e.integration.tests on my box. The tests start, and then hang on the first test, MEclipse181MultiLevelDependencyTest.testMultiLevelDependencies(), with the New Project wizard open in the test instance of Eclipse. Your patches apply cleanly now, but one of the tests still fails on my system junit.framework.AssertionFailedError: Expected generated annotations source folder. at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.eclipse.m2e.tests.configurators.AptProjectConfiguratorTest.testAgainstArtifactExclusions(AptProjectConfiguratorTest.java:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.PlatformUITestHarness$1.run(PlatformUITestHarness.java:47) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3933) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3610) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.runApp(NonUIThreadTestApplication.java:54) at org.eclipse.pde.internal.junit.runtime.UITestApplication.runApp(UITestApplication.java:41) at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.start(NonUIThreadTestApplication.java:48) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386) Any progress on this? It's biting us in the Google Plugin for Eclipse. We'd love to use APT with the maven-compiler-plugin, and have everything just "work" via m2e, but instead we have to rely on the maven-exec-plugin to invoke a post-processing version of what APT would do for us anyway: http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation While this does work, we have to force project at certain points in Eclipse in order to get the right behaviors.. (In reply to comment #34) > Any progress on this? It's been eclipsed in priority by some other work I've had, so no. However, I should be getting back to the project that required it next week. (In reply to comment #33) > Your patches apply cleanly now, but one of the tests still fails on my system Apologies, I'll try to take a look at this early next week. While waiting I've written m2e configurator. It's available at https://github.com/ilx/m2e-annotations Btw. This approach might not work if one uses AJDT on the same project that uses annotation processors. AJDT/aspectj doesn't play well with annotation processors. Hi, A few days ago, I've used Karl's patch to create a standalone plugin at https://github.com/fbricon/m2e-apt and made a dev build update site available at http://download.jboss.org/jbosstools/builds/staging/m2e-apt/all/repo/ What is really missing is the support for maven-annotation-plugin http://maven-annotation-plugin.googlecode.com/svn/docs/plugin-info.html. Ivica covers that part in his plugin (but misses the case where AP should be invoked directly without the need for maven-annotation-plugin. In the mean time, I also discovered Excilys' take on the subject at https://github.com/excilys/m2e-extras which uses a different approach : direct invocation of the maven-processor-plugin during incremental builds, without relying on Eclipse APT configuration whatsoever. This has the advantage of mapping maven's behavior 1:1, having the hability to use different output folders for main and test sources, which Eclipse-APT can't do, but you have to pay a performance penalty, as invoking javac -Dproc:only under the hood is way slower than APT's incremental build (as per my observations). I believe the ultimate integration should be able to let the user choose how AP will be performed : - on the workspace and project levels : use Eclipse APT or Maven or disable AP entirely - if Eclipse APT is chosen, then delegate everything to APT, use a central output directory for everything (target/generated-sources/m2e-apt/) so it doesn't collide with maven builds - if maven is chosen, then invoke javac -Dproc:only (unless -Dproc:none is set and if no maven-processor-plugin is used), or invoke maven-processor-plugin directly if needed, the way Excilys does. Builds will be slower but more "right" I shoulod also note that I had some strange behavor using Eclipse APT with the JBoss logging AP, where processing would not be perfomed, without anything helpful in the logs. Excilys' plugin was more reliable in that case. Fred's apt-plugin works fine for me, although i had to add the dependency of the annotation-processor in the normal dependencies. Before i only did specify the processor as depenendency in the maven-compile-plugin, where the processor was not found and nothing was generated. (In reply to comment #39) > A few days ago, I've used Karl's patch to create a standalone plugin at > https://github.com/fbricon/m2e-apt and made a dev build update site available > at http://download.jboss.org/jbosstools/builds/staging/m2e-apt/all/repo/ > ... Thanks very much for the fork and hosting of this, Fred. Funny that it's making it easier for me to use my own code today, but it is. I'm currently attempting to get approval to make contributions to your fork, but that may take a while. As discussed on IRC, I agree with your approach of getting this plugin merged with the other versions out there and then attempting to contribute it back to the m2eclipse project. As an FYI: your GitHub link earlier in the thread seems to be broken. Right I moved the m2e-apt plugin under the jbosstools organization : https://github.com/jbosstools/m2e-apt Sorry for the confusion. I've tried to use the m2e-apt plugin, and it's almost there for the processors we have. The issue is that that it currently does not parse the -A processor attributes from compilerArgument and compilerArguments elements from the plugin. I have a patch to get these things configured as well, whats the best way of getting it into another alpha build? Lorenz, you can fork https://github.com/jbosstools/m2e-apt and submit a pull request. Once it's reviewed, accepted and merged, a CI build should be available shortly after. You might need to sign a CLA for JBoss Tools at https://cla.jboss.org/, but I'm still waiting for Red Hat legal department about CLA matters. It *might* not be necesssary as the contribution can be traced via git / github and the code is EPL, but IANAL, we'll see. Thanks, I've published a pull request now. Looks like JBoos took over this http://dev.eclipse.org/mhonarc/lists/m2e-users/msg02547.html |