[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] [m2eclipse-dev] About lifecycle mapping extensibility
|
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
