Re: [m2e-dev] [m2eclipse-dev] About lifecycle mapping extensibility

[Igor Fedorenko <igor@xxxxxxxxxxxxxx>]

Quick observation, you are "hooking" to war-plugin and/or war packaging
type, but have additional conditions you need to check, i.e. presence of
certain dependencies.

--
Regards,
Igor

On 10-12-28 03:27 AM, Max Rydahl Andersen wrote:
> On Dec 22, 2010, at 06:02, Igor Fedorenko wrote:
>
> > Fred,
> >
> > I think having specific use case in front of us will make discussion
> > much more productive. Can you or somebody from JBoss Tools team provide
> > a sample project and explain how it builds on command line and what
> > should happen inside IDE? Don't worry about current or proposed m2e-core
> > API, assume m2e-core can do anything you want at this point.
>
> A quick response over the holidays:
>
> Our usecase for the configurators in JBoss Tools have primarily been that
> we enable the framework specific natures/facets based on maven dependencies
> and in some cases maven plugin usage.
>
> i.e. we enable basic CDI support in Eclipse (enables the CDI nature) if the cdi-api.jar artifact is referenced;
> and we enable the CDI Facet if the the project has the WTP WAR facet enabled (which it will have if the
> WTP-m2eclipse plugin is installed)
>
> Similar story goes for hibernate, seam, jsf and portal in our current code base:
> https://anonsvn.jboss.org/repos/jbosstools/trunk/maven/plugins
>
> Some of these does a little bit more; i.e. our Seam plugins needs to workaround MNGECLIPSE-2433
> (https://anonsvn.jboss.org/repos/jbosstools/trunk/maven/plugins/org.jboss.tools.maven.seam/src/org/jboss/tools/maven/seam/configurators/FixClasspathConfigurator.java) and we also need to setup additional metadata about certain directories (i.e. where is the model src folder, where is test etc. that we can get from the pom.xml) https://anonsvn.jboss.org/repos/jbosstools/trunk/maven/plugins/org.jboss.tools.maven.seam/src/org/jboss/tools/maven/seam/configurators/SeamProjectConfigurator.java
>
> Thus we basically doesn't hook into any plugin lifecycles; we purely (for now) extend upon the implicit usage of dependencies as a way to enable/disable features in IDE since that is what the user does by including the dependencies.
>
> /max
>
> > --
> > Regards,
> > Igor
> >
> > On 10-12-21 07:16 PM, Fred Bricon wrote:
> > > Hello World,
> > >
> > > as you may or may not know, m2e-core's API will change in the project
> > > configuration area, starting from v0.13 or later.
> > > First of all, I must confess I haven't looked at the new lifecycle API
> > > yet so feel free to bash me.
> > > After talking to Igor and *_from what I understand_*, project
> > > configurators will be bound to packaging type and/or mojo execution.
> > >
> > > The lifecycle mapping API is not finished yet, but that would probably
> > > mean if 2 plugins claim they need to configure the same packaging, an
> > > error message could be displayed to the user, asking him to choose which
> > > one to use, in the pom. That makes sense when these 2 plugins are
> > > competing against each other and I'm all for it.
> > >
> > > But if things go that way, in the case of WTP projects, if another 3rd
> > > party plugin - say JBoss Tools- needs to enhance current JavaEE projects
> > > behavior (adding JSF, Seam or more facets),
> > > it would first break current m2eclipse-wtp/jbt integration, then users
> > > would have to explicitely configure their pom.xml.
> > > I really think having to modify the pom.xml to adapt to the IDE is a
> > > wrong idea - IN THIS CASE -, when we could get it to work smoother.
> > >
> > > It'd be better, IMHO, if 3rd party plugins could "extend" or "contribute
> > > to" an existing lifecycle mapping.
> > >
> > > <discussion>open</discussion>
> > >
> > > regards,
> > >
> > > Fred Bricon
> > >
> > > --
> > > "Have you tried turning it off and on again" - The IT Crowd