On Feb 27, 2011, at 6: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.
having a special purpose packaging type just for IDE integration would severely limit the userbase of such IDE integration.
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.
there's 2 (slightly different) case here: 1. use has all of such integrations installed locally, the question which one to choose (if any) is more important here 2. one or all of the integrations are only potential future options, none are really installed.
in 1. I would as a user have expectation about one of the integrations being primary/preferred. I don't want to decide in one and every imported projects if it's webby or wtp. Just go with one as default and only have some markers (pom config section?) in the projects that are intended to be used with one of the integrations only.
when I change the preferred integration I want to be asked if all existing projects shall be reverted to the new default (unless they have hardcoded impl of course).
when for the first time I encounter a situation when 2 conflicting implementations are installed on my computer, I want to know what it means and want to pick the default.
I would consider a hardcoded implementation in the POM as an "advanced, hardcore" feature. not as primary way of interacting with projects.
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.
archetypes tailored for a specific eclipse IDE integration sound like a non-scaling idea.
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.
how is the author of the POM relevant here? Can't I as user have my own preference on how to work with the project? one uses webby, one netbeans, idea, WTP.. are you implying that certain projects won't be possible to work with with other tools?
Milos
-- 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
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
|
