Thank you for the answers and the wiki page -- its beginning to become clear.
However, I am still having problems. If I define multiple lifecycle-mapping pluginExecutionFilter, and then another in a parent pom, the effective pom only shows one of them (the first one defined in the local pom: excluding the second and the one from the parent pom). I also get a NullPointerException (see details below) -- which I assume might be a result of this discrepancy in the effective pom. I couldn't find a related bug for this... I also attempted to add the buildhelper plugin connector which also had NPEs. -Ben Errors running builder 'Maven Project Builder' on project 'apollo-taurus'. java.lang.NullPointerException at org.eclipse.m2e.core.internal.lifecyclemapping.model.PluginExecutionFilter.match(PluginExecutionFilter.java:304) at org.eclipse.m2e.core.internal.lifecyclemapping.SimpleMappingMetadataSource.getPluginExecutionMetadata(SimpleMappingMetadataSource.java:71) at org.eclipse.m2e.core.internal.lifecyclemapping.LifecycleMappingFactory.calculateEffectiveLifecycleMappingMetadata(LifecycleMappingFactory.java:294) at org.eclipse.m2e.core.internal.lifecyclemapping.LifecycleMappingFactory.calculateEffectiveLifecycleMappingMetadata(LifecycleMappingFactory.java:208) at org.eclipse.m2e.core.internal.lifecyclemapping.LifecycleMappingFactory.calculateLifecycleMapping(LifecycleMappingFactory.java:159) at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.setupLifecycleMapping(ProjectRegistryManager.java:526) at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:445) at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:327) at org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:278) at org.eclipse.m2e.core.internal.project.registry.MavenProjectManager.refresh(MavenProjectManager.java:58) at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:120) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) eclipse.buildId=I20110519-1138 java.version=1.6.0_25 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_CA Framework arguments: -product org.eclipse.epp.package.java.product Command-line arguments: -data c:\tools\eclipse\eclipse-indigo\workspace -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product On Fri, May 27, 2011 at 9:45 AM, Igor Fedorenko <[email protected]> wrote: > I wish it was that simple. > > First, "execute" was not the default. m2e had none less than four > different sets of maven goals it ran during project import, project > configuration update and workspace full and incremental builds. Some of > these were configured at workspace level, some in project/.settings. On > top of that there was project-level setting to "skip" > maven-compiler-plugin execution. > > Second, "execute" _is_ the root cause of missing resources, endless > builds and memory leaks, so making it the default basically blocks all > other possibilities to improve. > > Also, m2e 0.13 is much better at detecting incompatibilities and > reporting them. So when 0.12 was kinda-sorta-working-sometimes, 0.13 > creates those big red obvious error markers. We could hide the error > markers by default and let the users _guess_ what's going on. I don't > think there are too many projects that worked well in 0.12 and don't > work in 0.13, so most likely hiding the errors will make users feel > better about m2e 0.13 when comparing it with 0.12. At the same time I > believe failing fast and obviously is the right thing to do. > > -- > Regards, > Igor > > > On 11-05-27 02:31 AM, Jochen Wiedmann wrote: > >> On Fri, May 27, 2011 at 6:02 AM, Igor Fedorenko<[email protected]> >> wrote: >> >> Of course, there is a chance we overlooked another, simpler solution, so >>> if you think you know how to make m2e work reliably and efficiently with >>> all/many projects while failing gracefully for the rest, please bring >>> this up on m2e-dev and I will see how is the best to schedule this. >>> >> >> For example, how about default=execute, at least while developing the >> metadata library? That would, IMO, spare us this discussion and lots >> of similar discussions in the near future? And, if I get things right, >> we'd had not a worse state than we had before. (Which we currently do, >> IMO. I struggled about one hour yesterday in the evening in trying to >> get my poms working. Although there was definitely another problem in >> m2e as well, which I'll report later on, so the lifecycle mapping >> isn't the only thing to blame.) >> >> Jochen >> >> >> _______________________________________________ > m2e-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/m2e-users > -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
_______________________________________________ m2e-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/m2e-users
