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

[Benson Margulies <bimargulies@xxxxxxxxx>]

Bingo! Thanks.

On Wed, Jan 19, 2011 at 9:46 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
> In 0.13, IMavenProjectFacade.getExecutionPlan already includes all
> lifecycle phases.
>
> Calculating execution plan to get configuration of a single plugin
> execution has two undesired consequences. First, it can be slow,
> especially with empty local repository, when Maven has to read to all
> remote repositories to retrieve all referenced maven plugins. Second, if
> any of the plugins cannot be resolved for whatever reason, calculation
> of entire execution plan fails.
>
> To solve both of these problems we plan to introduce additional APIs to
> allow project configurators access individual plugin execution
> configuration without the need to resolve complete execution plan. This
> is next on my to-do list. You can watch MNGECLIPSE-2724 to monitor the
> progress.
>
>
> https://issues.sonatype.org/browse/MNGECLIPSE-2724
>
> --
> Regards,
> Igor
>
> On 11-01-19 09:23 AM, Benson Margulies wrote:
>>
>> 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
>>>
>> _______________________________________________
>> 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
>