Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-users] Plugin execution not coveredby lifecycleconfiguration


What about a LifeCycleMapping contribution preference page. Something where lifecyclemappings can be contributed to a Preference Page in eclipse, they can be imported and exported. This way an eclipse plugin is not necessary for those that need just basic configuration.

Another suggestion is to add a simple Sources and Resources configuration section to the lifecycle mappings.

So if somebody wants the action to be <execute/>  they can also add:


This way you put more of the configuration and maintenance into manageable Lifceyclemapping.xml files that can be distributed and shared amongst team members.

I do think keeping the plugin contribution ability is a good thing, but also think we need to give the user a bit more control. Plus this way, you don't have to store stuff in the POM, it's stored in the Eclipse Preferences, and can be imported and exported. It's keeping the eclipse specific items with eclipse with out having to clutter up the poms with eclipse specific items.


On 06/27/2011 10:44 AM, Igor Fedorenko wrote:
We could not find a general solution that would properly and reliably
work for all Maven projects. The old "default" behaviour available in
0.12 did not work for large enough number of projects to make it
prohibitively expansive for our team to support. I strongly believe
opensource is about community working together to solve common problems.
Our primary goal right now is to help m2e community build library of m2e
extensions that provide lifecycle mapping for various maven plugins. I
don't think it is fair to expect m2e dev team to provide
out-of-the-box support for all maven plugins.


On 11-06-27 6:02 PM, Jochen Wiedmann wrote:
On Mon, Jun 27, 2011 at 3:07 PM, Igor Fedorenko<igor@xxxxxxxxxxxxxx> wrote:

For example, none of "mojo" enhancement
requests we received so far [1] can be supported by neither<ignore/>
nor<execute/> mapping, so improving ways to stores these mappings seems
like a wrong problem to solve.

After reading that list, I am really unsure, whether you considered
all possible alternatives.

For example, let's say I am just assigning a Maven goal like
"generate-resources" and have the project builder run that. Much like
the Ant builder, which invokes a target. (And, if I remember right,
much like what has been done in the past.)

Okay, I admit that I am missing a few settings like folders with
generated sources and stuff like that. But so far, I was always happy
with a manually generated build path in the project. In contrary, I am
unhappy with the new way in 1.0.0, which frequently forces me to run
"Update project configuration", discarding my manual project settings.

IMO, the new M2E wants to be really clever. I have to admit, that I
would prefer it to be not so clever while maintaining the feeling that
I can control it.

Proprietary plugins. I probably emphasize m2e marketplace catalog little
too much. Even though the catalog provides convenient way to discover
and install m2e extensions, it is not required. Proprietary plugins can
be supported by m2e extensions available from an update sites only
visible on company's intranet or come as part of a custom eclipse
distro, for example.

That's not good, Igor. Please note: We are Eclipse *users*, not
*developers*, like you.

We are managing Maven projects, not Eclipse projects. We've got Nexus
up and running, but are far from having an Eclipse update site. Having
played with Tycho a little bit, I find the maintenance of an update
site extremely cumbersome and hard. For example, I haven't yet found a
way how to integrate a new version while preserving existing versions
in the catalog.


m2e-users mailing list

Back to the top