[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] multiple mappings for the same packaging type or maven plugin execution
|
If a team settled on a specific set of m2e extensions and coded this
decision in project's pom.xml file, then I completely agree m2e should
just use whatever is specified in the pom. This is how current master
HEAD is expected to work already.
My proposal is about projects that do NOT have m2e-specific
configuration in their pom.xml files. Up until now I assumed it was
important to provide reasonable support for such project. I don't think
it is reasonable to force everyone to change their pom.xml files to be
able to use m2e, however, multiple providers of support for the same
packaging type and/or plugin execution can be rare enough to justify
this requirement.
--
Regards,
Igor
On 11-02-27 12:38 PM, Jason van Zyl wrote:
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>
<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 <mailto:m2e-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________
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
---------------------------------------------------------
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 <mailto: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
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
