On Feb 27, 2011, at 8:59 AM, Jason van Zyl wrote: On Feb 27, 2011, at 8:53 AM, Igor Fedorenko wrote: Different groups providing support for war packaging.
So in your estimation do we have any other cases right now like multiple competing implementations for the war packaging?
Could this be simplified by our users of webby using a sonatype-war packaging to clearly distinguish them? We are likely to provide an augmented WAR plugin anyway. Though this would not preclude someone from using WTP with sonatype-war I supposed.
This is probably the best example to walk through in full detail to see how it works. Then see how it can be simplified most for the users and the providers.
I think we are dealing with the potential of IDE integration and Maven plugin integration. If we base this off the packaging type only then we are dealing with different IDE integration trying to key off the "war" packaging type. In this case do we expect the person who configured the POM to know nothing, or should be expect them to put something in the POM that would indicate the use of WTP versus Webby (or whatever else) for example. Or try and catch this on import of project where the person who made the POM has no idea about the integrations that are possible.
So is you questions do we only support a POM that has knowledge of the integration, or try to help on import?
For web integration I can already think of three examples, stock WTP integration, JBoss flavor WTP integration, and our Webby. Could this not be controlled specifically by the POM and thus making archetypes specifically which indicate how the integration for a particular project type should work? This way any project, or vendor can have complete control over how the integration works.
I don't understand when you say that "not supported" is just as hard as supporting on import when we could say just set your POM up properly and show people how to do it. It's one thing to support the lifecycle mapping, but controlling which IDE integration can be fully controlled from the POM can't it? In the case of multiple competing implementations nothing is default and it's up to the author of the POM to include the right instructions. I think that's fair everyone. If we find this is highly problematic and killing users because no one is configuring their POMs then maybe we consider doing the work to make it work on import but that's a lot of work.
-- Regards, Igor On 11-02-27 08:37 AM, Jason van Zyl wrote: Are you specifically talking about different version of a packaging that
have different mojos in the phases, or two different groups providing
mappings for say the WAR packaging?
On Feb 26, 2011, at 11:56 PM, Igor Fedorenko wrote:
What will happen if several m2e extensions provide alternative/competing
support for the same project packaging type or plugin execution? This
question came up several times already and our answer so far was "not
supported".
While working on m2e extension discovery implementation, I've realised
that proper implementation of this "not-supported" approach ends up
quite involved. Implementation basically needs to detect conflicts among
all new and installed m2e extension, which is not easy.
Another major limitation of "not-supported" approach in my opinion, is
that it is not possible to import project with explicit lifecycle
mapping configuration in pom.xml, if it happens to conflict with
currently installed m2e extensions. Again, we need to detect the
conflict and basically do not allow the import. Again, not easy to
implement. It will also be rather "surprising" to the user and not in a
good way.
I think m2e should provide proper support for alternative/competing
extensions and [1] explains how I think we can do it. Development effort
should be about the same as providing proper "not-supported"
implementation, so I see no reason to stick with inferior approach.
What do you think? Any objections I schedule this work for M7?
[1]
https://docs.sonatype.org/display/M2ECLIPSE/multiple+mappings+for+the+same+packaging+type+or+maven+plugin+execution
--
Regards,
Igor
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/m2e-dev
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________ m2e-dev mailing list m2e-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/m2e-dev
Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl---------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl---------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
|
