Re: [m2e-users] Long term outlook for 'M2E plugin executionnotcovered'

[Benson Margulies <bimargulies@xxxxxxxxx>]

It seems to me that this discussion is based on a false comparison.
There are maven plugins, Eclipse plugins, and other IDE plugins. No
supernatural force is going to take the configuration data for the
maven-checkstyle-plugin and turn it into configuration for the Eclipse
checkstyle plugin. Or, to look at it another way, no magic force can
render the results of checkstyle (as run inside Maven) into the data
that Eclipse would need to add wiggly lines and other markup.

IDEs come in two flavors. IDE's like XCode and NetBeans run some other
build tool underneath, so that basic behavior is covered once you
configure the underlying build tool. If you stick the checkstyle ant
task into your netbeans project's ant file, you will run checkstyle
inside netbeans. The results may not be terribly illuminating, but it
works. IDEs like Eclipse and Visual Studio take responsibility for the
whole build, so they can't do anything at all unless something maps
out even the basic build configuration for them. Some people really
hate Eclipse exactly because it is a 'deep' IDE in this sense.

We might imagine a sort of ur-API for build tools and plugins, perhaps
implemented with some language-neutral data format like json, by which
all the build tools and their plugins could interact with IDEs with
tight integration. We could imagine it, but it doesn't exist, and it
isn't very likely to show up.

The maven-eclipse-plugin exists, and works pretty well in many cases.
When you want to use a plugin that it has no special knowledge of, you
have to script the corresponding eclipse configuration. Apache CXF is
an example of just how far you can take this scheme. If you wanted to
make it extensible to avoid this, you'd end up in the same place:
inviting people to write bits of code to bridge maven plugin and their
configuration to Eclipse plugins and their configuration.

As the author of some barely non-trivial m2e configuration plugins, I
can say from experience that the situation is somewhat rough, and will
remain somewhat rough until there is a critical mass of good examples
to steal from. Only time will solve this. Heaven help someone who
tries to use my code as a good example to steal from.

If you really love the old m2eclipse, well, open source is its usual
wonderful thing. Go find the source, rename the bundles, and adapt it
to the version of Eclipse that you need.

As for 'ugh, stuff in my POM' -- aside from Igor's offer to
incorporate an alternative, I would point out that over in Maven-land,
there's an active discussion of the next generation POM, and one idea
in the air is make POMs work like W3C XML schemas: other tools could
look for annotations in other XML namespaces to avoid the annoyance of
keeping multiple files in sync. If we actually pull this off, m2e
could have annotations, and netbeans, and anything else that cared to.

No doubt this idea is not to everyone's taste.

Me, I'm waiting for the ordinary 'debug-as/java app' to stop mixing in
the eclipse test classpath, which, in my experience, has always been
the biggest pitfall of combining the two. Or has m2e got that going
now and I haven't noticed?