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

[Benson Margulies <bimargulies@xxxxxxxxx>]

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
>