Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-users] Long term outlook for 'M2E plugin execution not covered'

Am 09.08.11 19:15, schrieb Max Rydahl Andersen:
>> 1. Maven plugin authors need to worry about which IDE their users use,
>> they need to provide explicit Eclipse integration along with their
>> plugin. It feels wrong that when writing a Maven plugin I need to
>> worry about IDEs (rather than simply Maven itself), an indication that
>> m2e has taken the wrong path here. Where plugins are concerned, m2e
>> appears to effectively no longer integrate with Maven, it needs an
>> additional 'integration layer' to be written across the plugin
>> universe. I'm confused and amazed by this design decision.
> As long as IDE's and build tools doesn't do exactly the same thing in all cases
> this has always been and always will be a concern.
> (if they did - why are there more of them ? :)
>  
> Maven, Netbeans, eclipse and intellij already have different behaviors - it might just not 
> be completely obvious to you in daily life but they do.
>
> it is something I agree with the m2e team on that users should be made aware of - they
> need to take a conscious choice if they want to actually have maven execute the maven plugin (
> with all the possible side effects that will have) or ignore it.
>
> Previously M2e just executed it which resulted in countless cases of performance bugs
> and very hard to find bugs because the maven plugin was not considering the much more incremental
> environment and concurrent aspect of an IDE.
>  
> So something had to be done - m2e dev's went all out with putting Error markers and ignore the plugins
> they did not have info about (I would have made it Warning markers and ignore and I believe that would 
> make people understand this issue much better).
>
>> 2. Projects using Maven need to add IDE-specific (Eclipse-specific)
>> configuration into their pom, or worse individual developers that work
>> on a project need to customize their local sources before Eclipse can
>> even build a Maven project.
>> Bug 350414 should go some way to address
>> this if fixed right, but no doubt Eclipse will still allow the
>> lifecycle mappings to the pom where they really do not belong.
> I agree it should be an option - but I do not agree they they don't belong in the pom.
> It's a great way of sharing the settings without introducing more files into your SCM and
> it doesn't affect your normal maven setup.
>
>> In the
>> short term (where the POM is the only place these mappings are
>> supported), I believe Indigo/m2e is not viable for many, many
>> projects, since adding IDE specific configuration will be deemed
>> unacceptable by project owners.
> Please note that maven still build your project even with these error markers.
> it just doesn't execute the plugins for you - if it did then we would be back to having
> all the problems that made m2eclipse unstable before.
>
>> Is there any chance that for Indigo SR1 or SR2 the m2e dev team will
>> revisit this lifecycle integration in a fundamental way that will
>> address these problems? Maybe it's possible to learn from the Maven
>> integration done by other IDEs?
> If you know of an IDE that does it better let me know.
>
> Last I checked netbeans just delegate to Maven == SLOW!
> And intellij reads some parts of the metadata and ignores the rest == Hiding the errors.
>
> (this was last year - if things has changed I would love to hear)
>
> /max
> http://about.me/maxandersen
I think, you rotate the the view.  Maven is the tool, which  m2e plug-in
must be integrate. That mean, that all possibility, what you can make
with mvn on the console, must be work with m2e plug-in. Or ?  
>
>
>
> _______________________________________________
> m2e-users mailing list
> m2e-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2e-users



Back to the top