On Aug 9, 2011, at 4:59 PM, Max Rydahl Andersen wrote:

>>> Let's say there are two kinds of users:
>>> a) Some who would like maven/ide plugin to be aware of the IDE build 
>>> process and project output locations so that they can experience really 
>>> fast edit/build/test cycle.
>>> 
>>> b) Others who would like maven/ide plugin to delegate the build to maven 
>>> completely. These users either don't face or don't care for the performance 
>>> problem because of various reasons which are not important for this 
>>> discussion.
>>> 
>>> If m2e can provide an option to be configured to operate in mode #b, then 
>>> neither group has to sacrifice. I will let m2e developers tell us how 
>>> difficult it is to support this additional mode.
>>> 
>> 
>> If you want option b) then your use case is already supported. Use the 
>> maven-eclipse-plugin to generate your eclipse files and then just do your 
>> build with Maven configured as an external tool. Every time you make changes 
>> to your POMs you just generate the Eclipse files again.
> 
> Well, the better way would be to import with m2e, let it update the project 
> configuration as good as it can (its way better than the 
> maven-eclipse-plugin) and then just disable/enable m2e on the projects when 
> you need/want it.
> 

This requires almost everything we do now. Let's take source generation for 
example: you would still need to use configurators in order to generate sources 
and make the workspace aware of those sources. Otherwise a user imports a 
project and sources they need are not available. You either need to run Maven, 
an individual mojo or a configurator. Additionally it would just be even more 
confusing having two primary modes of operation and the surface area to support 
becomes problematic again. 

Users will complain that things don't work and I don't believe this is viable. 
I'm only interested in making it work properly which I consider full 
integration. I certainly wouldn't expend any effort here trying to make b) 
work. If you want static, non-realtime integration with Maven then the 
maven-eclipse-plugin is what you want.

> /max
> 
>> 
>>> Thank you very much,
>>> Sahoo
>>> 
>>> On Tue, Aug 9, 2011 at 10:45 PM, Max Rydahl Andersen 
>>> <[email protected]> wrote:
>>> 
>>>> 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
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> m2e-users mailing list
>>> [email protected]
>>> https://dev.eclipse.org/mailman/listinfo/m2e-users
>>> 
>>> _______________________________________________
>>> m2e-users mailing list
>>> [email protected]
>>> https://dev.eclipse.org/mailman/listinfo/m2e-users
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> Selfish deeds are the shortest path to self destruction.
>> 
>> -- The Seven Samuari, Akira Kurosawa
>> 
>> 
>> 
>> _______________________________________________
>> m2e-users mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/m2e-users
> 
> /max
> http://about.me/maxandersen
> 
> 
> 
> _______________________________________________
> m2e-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/m2e-users

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance



_______________________________________________
m2e-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/m2e-users

Reply via email to