Maven Project Build Lifecycle Mapping Problem in Eclipse

[mathias]

I set up Eclipse Luna and the m2e maven plugin. Finally I setup an initial vert.x project with maven archetype following this guide: http://vertx.io/maven_dev.html#setup-your-ide
Now, the project shows two errors in the pom.xml. One in line 190, and the other in line 201. Both problems seems to have the same cause:

Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-dependency-plugin:2.7:copy-dependencies (execution: copy-mod-dependencies-to-target, phase: process-classes)

Is it an IDE related problem, maven related or even setup related problem?
I couldn't find any solution yet. Any help is appreciated.

[Alexander Lehmann]

you can mostly ignore that, eclipse will still properly run the build operations if you select run as maven build.

[dgo...@squaredfinancial.com]

The m2e plugin for eclipse:

https://www.eclipse.org/m2e/

m2e offers very tight integration with eclipse for maven projects.  But there can be problems with various maven plugins, like in this instance, for reasons - it's a slightly complicated issue to explain, and not really anything to do with vertx specifically so I won't try to go into it, just link to the explanations. A TL;DR is that you can currently put a "lifecycle mapping metadata" declaration in a certain part of the eclipse settings "Maven->Lifecycle Mappings" as a workaround (or into the pom - but that uglifies the pom with eclipse-specific gibberish so I discourage it) to wallpaper over it.  (There's also apparently now a mechanism for maven plugin authors to supply the metadata, so the issue can suddenly disappear for a given plugin). As another poster noted, you can mostly ignore it ...mostly... but if you'd rather not:

http://stackoverflow.com/questions/8706017/maven-dependency-plugin-goals-copy-dependencies-unpack-is-not-supported-b
http://wiki.eclipse.org/M2E_plugin_execution_not_covered
http://wiki.eclipse.org/M2E_compatible_maven_plugins#Overview

The maven-eclipse-plugin for maven:

http://maven.apache.org/plugins/maven-eclipse-plugin/

But note also there are really two different approaches when working with maven+eclipse, one with eclipse "in charge" (the m2e plugin for eclipse) and one with maven "in charge" (the eclipse plugin for maven).  It can get pretty confusing if you mix them up or try to mix the two.

The maven "in charge" approach i.e. maven-eclipse-plugin can be easier and more reliable (YMMV), even though at first glance it might sound like it should be rather more awkward.  It doesn't try for such tight integration, just spits out and updates eclipse project definitions. Basically, with a maven project generated by the vertx maven archetype, say:

Firstly, it's best to tell the maven eclipse plugin the correct path to your eclipse workspace (see the docs) and do a "mvn eclipse:configure-workspace", once per workspace  (note if you were using the m2e eclipse plugin, they both expect a M2_REPO eclipse classpath variable and that's basically what it's setting up, so it may already be there)

run "mvn eclipse:eclipse" and "File->Import->Existing projects into workspace" the generated eclipse project into eclipse.

Whenever you make a change to the pom itself, briefly "Close Project" in eclipse (from the right-click menu on the project) (or whole workspace if you're feeling extra-paranoid), rerun "mvn eclipse:eclipse" and then re-"Open Project" in eclipse.

Then, ignore the eclipse facilities to "run" the project, and have a shell window nearby and use a "mvn vertx:runMod" or  "vertx runMod foo~bar~1.2.3" after a "mvn vertx:init" (which is really making an appropriate module.link file in the vertx mods/ dir).   Or there are ways to make hitting the intra-eclipse run actually do it,  see e.g. Run->External Tools...

Even if using the maven eclipse plugin approach, you can also leave the m2e eclipse plugin installed and use its intra-eclipse fancy pom editor - just don't actually give the project an intra-eclipse maven nature (see the "Configure" branch on the project's right-click menu), even so the pom editor still works fine.

[mathias]

It is still amazing to see how computers are able to create problems that we wouldn't have without computers :-)
On on hand it is "funny" but on the other it smashed me down because I didn't expect so much information on this issue in the first place.
However, thank you very much for your dedicated support. It helped me a lot in understanding the issue better.

All "solutions" that I have found so ffar seem to be either complicated or ugly in my eyes. But I am luky and found a simple "solution" in eclipse by myself which I would like to share:
Eclipse allows to ignore this kind of message in the way you want it. Just go to Window->Preferences->Maven->Errors/Warnings and change the warning level for the last element "Plugin execution not covered by lifecycle configuration" to either warning or ignore.

What whay do you recommend to run a module when using eclipse+debugging? External Tools or using the console command vertrx runmod or just maven?

[Alexander Lehmann]

I am currently using either unit tests or integration tests (works with debug as ... unit test) or I use mvnDebug to run the vertx:runMod command in a normal maven in the command shell and attach to that with remote debugging in Eclipse.

both works rather well, other debugging stuff I just do with logging inside vert.x and change the logging statements inside eclipse for the maven module task to pick up, that is rather old school, but it works well for my project.

[dgo...@squaredfinancial.com]

On Thursday, 14 August 2014 13:30:25 UTC+1, Alexander Lehmann wrote:

both works rather well, other debugging stuff I just do with logging inside vert.x and change the logging statements inside eclipse for the maven module task to pick up, that is rather old school, but it works well for my project.

If you use slf4j with a logback backend, you can then use logback "beagle" to shove them back into the eclipse ui. This isn't entirely pointless as you can then jump straight to the statement that did the logging from the ui. 

vertx 2 platform's logger name-mangling and delegation makes it a bit ugly in the beagle view if you use the supplied vertx logger instead of just an slf4j one directly, say, but not unusable. (The beagle tree view gets slightly weird because it interprets the logger name - and vertx 2 always munges a module name in there (or null for just verticles). And you have to expand the call tree and go a couple of lines back to "your" call to jump to the right caller because of the delegation. And see logback bug #905 if "jump to caller" doesn't seem to work at all)