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

[Benson Margulies <bimargulies@xxxxxxxxx>]

Sure.

People use checkstyle and pmd in maven.

The goal is to take the exact configuration from the maven plugins and
push it into the corresponding eclipse plugin.

A parent project might have a pluginManagement that supplies some of
the configuration, while the leaf project might add or override some
of them.

When someone runs maven, these various overlapping sections are
resolved into a set of properties that make up the configurations for
a particular execution. That's the properties that I want to turn
around and push into the corresponding eclipse plugin.

I thought I was being pretty clever to use the execution plan to get
this, but people have asked me to make this work even when they bind
the plugin to a phase that isn't in the relevant execution plan.

--benson




On Wed, Jan 19, 2011 at 9:12 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
> Can you explain what you are trying to achieve?
>
> --
> Regards,
> Igor
>
> On 11-01-18 10:20 PM, Benson Margulies wrote:
>>
>> Igor,
>>
>> I'd love to go try this out with the checkstyle/pmd stuff. Could you
>> possibly help me out by answering the following question I posed on
>> the maven user list?
>>
>> Consider a project with an arbitrary structure of parent that might
>> contain plugins and plugin management.
>>
>> In an M2Eclipse plugin I'm maintain, I am asking the question:
>>
>> "Is there an execution of GROUP:ARTIFACT:GOAL, and, if so, what is the
>> contents of the<configuration/>  element?"
>>
>> I currently do this by walking an execution plan.
>>
>> This depends on the plugin being bound to a phase in the lifecycle
>> used to build the execution plan.
>>
>> users have asked me if I can't come up with some other scheme that
>> does not require the lifecycle binding.
>>
>> Is there a way to navigate the plugins of the 'effective pom' to this
>> effect using the API?
>>
>> --benson
>>
>>
>> On Tue, Jan 18, 2011 at 7:54 PM, Igor Fedorenko<igor@xxxxxxxxxxxxxx>
>>  wrote:
>>>
>>> FYI, I've just pushed implementation of "secondary" project configurator
>>> support [1] and corresponding test [2].
>>>
>>> At this point we are mostly done with changes to lifecycle mapping and
>>> project configuration API. Now is a good time to start looking at it and
>>> give us feedback whether the new API works or does not work for your m2e
>>> extensions.
>>>
>>> [1]
>>>
>>> http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=d24be2000cccd5bd4dff3dd8ef6227f3f3a1a5ad
>>> [2]
>>>
>>> https://github.com/sonatype/m2e-core-tests/commit/94694312fa6368254fba5353b9fa00027b76db6d
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>>
>>>
>>> On 11-01-15 12:51 AM, Igor Fedorenko wrote:
>>>>
>>>> Our goal for build lifecycle mapping work is two fold. First, for any
>>>> maven project, we want m2e to be able to tell with reasonable confidence
>>>> if current eclipse installation supports development of the project or
>>>> not. Second, we want m2e to be able to find and offer installation of
>>>> additional components needed to support the project. So when somebody
>>>> imports a war project into a stock m2e installation, we want m2e to tell
>>>> the user that war development is not supported but m2e-wtp can be
>>>> installed to provide such support should the user allows m2e to do so.
>>>>
>>>> Our current thinking is to base "supported/not supported" determination
>>>> using combination of project packaging type and maven plugins bound to
>>>> project build lifecycle. On command line, these fully define build
>>>> behaviour and results and thus provide direct indication of IDE features
>>>> required to work on the project.
>>>>
>>>> We also believe that "supported/not supported" determination should be
>>>> metadata-driven. This is needed to enable discovery and installation of
>>>> additional required components. As added benefit, it will also allow m2e
>>>> to avoid unnecessary bundle activation, which I believe is one of soft
>>>> requirements for release train participants.
>>>>
>>>> Although project configurator API remains mostly unchanged in 0.13.x,
>>>> m2e core will not blindly call all installed configurators for all
>>>> workspace projects any more. Instead the core will use "the build
>>>> lifecycle mapping metadata", as we call it, to only invoke applicable
>>>> project configurators.
>>>>
>>>> This mapping metadata can contain two element types.<lifecycleMapping/>
>>>> tells m2e what lifecycle mapping strategy it should use for what
>>>> packaging type.<pluginExecution/>  tells m2e what project configuration
>>>> it should use what plugin execution. m2e considers a maven project
>>>> "supported" if there is one and only one mapping element for project
>>>> packaging type and each interesting plugin execution.
>>>>
>>>> Couple of real-world mapping metadata examples
>>>>
>>>> [1]
>>>>
>>>>
>>>> https://github.com/sonatype/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/lifecycle-mapping-metadata.xml
>>>>
>>>> [2]
>>>>
>>>>
>>>> https://github.com/sonatype/m2eclipse-extras/blob/master/org.maven.ide.eclipse.temporary.mojos/lifecycle-mapping-metadata.xml
>>>>
>>>>
>>>>
>>>> And now, finally, I get to JBoss Tools Maven integration ;-)
>>>>
>>>> We discussed this internally, and we think m2e core can support your use
>>>> case by extending mapping metadata with notion of "secondary" project
>>>> configurators. When finding mapping for a plugin execution, m2e core
>>>> will require one and only one regular (or primary) configurator, but
>>>> will allow any number of secondary configurators. The core will
>>>> guarantee primary configurators are invoked before their secondaries.
>>>>
>>>> For example, mapping for the CDI configurator will tell m2e to enable
>>>> the CDI configurator for maven-compile-plugin as secondary to the java
>>>> configurator from m2e-jdt.
>>>>
>>>> We do not plan to add metadata to describe fine-grained configurator
>>>> activation conditions like "if cdi-api.ja artifact is present on
>>>> classpath". As a consequence of this, m2e will not be able to reliably
>>>> detect if secondary configurators are required or not and will not be
>>>> able to automatically discover and install them. So users will have to
>>>> download and install JBossTools manually.
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>> On 11-01-05 12:39 PM, Snjezana Peco wrote:
>>>>>
>>>>> JBoss Maven Integration includes five Maven Configurators. Some of them
>>>>> work with WTP projects (war, ejb or ear), some with simple Java
>>>>> projects.
>>>>> The CDI configurator, for instance, enables CDI capabilities if a
>>>>> project contains the javax.enterprise:cdi-api dependency. The project
>>>>> can, but doesn't have to be a WTP project.
>>>>> All our configurators depend on m2-eclipse wtp and m2eclipse Java
>>>>> configurators. They have a higher priority and suppose that m2eclipse
>>>>> configurators are executed. For instance: the JSF configurator adds the
>>>>> WTP JSF facet to the project. It considers that the m2eclipse-core
>>>>> configurator has created a Java project and the m2eclipse-wtp
>>>>> configurator has created a WTP project and added the base facets (Web
>>>>> Module, Java Facet ...).
>>>>> The JBoss Maven Configurators aren't the only configurators dependents
>>>>> on other configurators. Some WTP configurators (war, ejb) depend on
>>>>> Java
>>>>> configurators.
>>>>>
>>>>> Snjeza
>>>>>
>>>>> Igor Fedorenko wrote:
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>
>>>> _______________________________________________
>>>> m2e-dev mailing list
>>>> m2e-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/m2e-dev
>>>
>>> _______________________________________________
>>> m2e-dev mailing list
>>> m2e-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/m2e-dev
>>>
>> _______________________________________________
>> m2e-dev mailing list
>> m2e-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/m2e-dev
>
> _______________________________________________
> m2e-dev mailing list
> m2e-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2e-dev
>