[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] lifecycle-mapping-metadata.xml for a plugin goal that is not bound to a lifecycle
|
see inline
On 1 September 2011 16:04, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
> see inline
>
> --
> Regards,
> Igor
>
> On 11-09-01 10:09 AM, Phil Webb wrote:
>>
>> Hi Igor,
>>
>> Thanks very much for the pointers. The modello model and the mapping
>> file in org.eclipse.m2e.lifecyclemapping.defaults helped a lot with my
>> understanding.
>>
>> I guess for now you are saying that there is no extension point that
>> will do exactly what I need, I have had some success binding to the
>> maven-clean-plugin so I will probably continue with this approach for
>> now. Perhaps in a future release there could be a way of attaching
>> AbstractProjectConfigurator instances that are not bound to any
>> specific goal? Is it worth me opening a bug for this?
>
> There needs to be a way to decide if such configurators apply to any
> given project or not. Otherwise, bundles contributing such configurators
> will be early/unconditionally activated, which is something we'd want to
> avoid.
>
For me the decision is based on the maven-eclipse-plugin being defined
in the POM. Perhaps the <goals> section of the
lifecycle-mapping-metadata.xml could be option to indicate that if
there is a dependency on a plugin, regardless of what goals are bound
the configurator should apply?
>>
>> As for the blocking of the maven-eclipse-plugin, I don't think this
>> will cause a problem. You do indeed get an error if one of the
>> eclipse goals is bound to a lifecycle but if you simply make reference
>> to the plugin and do not bind a goal then the project will import
>> correctly. This is the scenario I am anticipating.
>
> That would be a bug ;-) m2e is supposed to reject import of projects
> with .classpath and/or .project files generated by maven-eclipse-plugin.
> Since we have not got any bugreports related to use of
> maven-eclipse-plugin with m2e, I am not going to investigate/fix this.
>
I had not actually tested all scenarios. I don't think there is a bug.
1) pom that includes maven-compiler-plugin but no <execution> binding
a goal to a phase:
a)
mvn eclipse:clean
Import existing maven projects
result = no problems
b)
mvn eclipse:clean eclipse:eclipse
Import existing maven projects
result = No obvious errors but a comment inside the .projectfile
"NO_M2ECLIPSE_SUPPORT: Project files created with the
maven-eclipse-plugin are not supported in M2Eclipse."
1) pom that includes maven-compiler-plugin with an <execution> binding
a goal to a phase:
a)
mvn eclipse:clean
Import existing maven projects
result = Error : maven-eclipse-plugin is not compatible with m2e
b)
mvn eclipse:clean eclipse:eclipse
Import existing maven projects
result = As above.
This is pretty much exactly what I would expect. You can define the
maven-eclipse-plugin for people to use if they don't have m2e and it
works as long as they are not stupid enough to run "mvn
eclipse:eclipse". If you bind to an "eclipse:whatever" goal then m2e
can't support that and fails.
>>
>> Thanks for your help.
>>
>> Cheers,
>> Phil.
>>
>>
>>
>>
>> Igor Fedorenko wrote:
>>
>> There is no documentation of lifecycle mapping file format, but it is
>> generated from modello model [1], which should provide information about
>> all supported elements. If you have more specific questions, we'll try
>> to answer them here.
>>
>>
>> As name suggests, lifecycle mapping only applies for plugins bound to
>> project lifecycle. What you are looking for is some sort of generic
>> extension point that will be invoked during project import and
>> configuration update but I am not sure how to implement this efficiently.
>>
>>
>> Also note that currently m2e blocks projects generated by
>> maven-eclipse-plugin (or at least it should). We did that because we
>> were getting many bugreports who generated .project/.classpath/etc using
>> maven-eclipse-plugin and then expected m2e to dynamically manage
>> dependencies and other aspects of project configuration. You'll have to
>> convince us your solution works reliably before we lift this restriction.
>>
>>
>> [1]
>> http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.core/mdo/lifecycle-mapping-metadata-model.xml?id=releases/1.0/1.0.0.20110607-2117
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 11-08-31 10:36 AM, Phil Webb wrote:
>>
>> I wonder if anyone can provide some advice when working with the new
>> lifecycle-mapping-metadata.xml configuration file that is part of m2e
>> 1.0.
>>
>>
>> 1) Is the format of this file documented anywhere, or is there any
>> particular part of the codebase that describes the format?
>>
>>
>> 2) Is it possible to setup a pluginExecution for a goal that is not
>> bound to a lifecycle. Specifically I am trying to write a plugin that
>> will support settings such as additionalProjectnatures defined in the
>> maven-eclipse-plugin configuration
>>
>> (http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html).
>> Since this plugin is usually executed manually on the command line,
>> and not run as part of the the regular build, defining a
>> pluginExecutionFilter against the maven-eclipse-plugin does not seem
>> to work.
>>
>>
>> Any advice would be gratefully received.
>>
>>
>> Cheers,
>> Phil.
>> _______________________________________________
>> 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
>
