The marriage of eclipse and maven poses fundamental challenges that don't exist for Intellij or Netbeans.
Of the three major Java IDE's, only Eclipse incorporates its own classpath and compiler system. IJ and NB 'just run maven' and analyze the output for display. Eclipse, on the other hand, actually compiles. Further, Eclipse builds WAR files, and runs tools like checkstyle, pmd, and findbugs via its plugin architecture -- typically with an entirely different configuration system than maven's. Each of m-e-p and m2e is an attempt to bridge these gaps. m-e-p can't solve the problem that eclipse has one classpath and maven has two, nor the problem of bridging configuration one plugin at a time. m2e, on the other hand, has a very difficult hill to climb. mvn and eclipse each has a complex class loader system. At best, the result of running maven inside the eclipse jvm is an even more gigantic thirst for memory (and particularly permgen space). m2e's long-term success depends on eclipse changes to accomodate the maven classpath model. It's also just a giant effort of a small group of people. Dealing with the Eclipse release train system doesn't make their life any easier, either. The net result is that many people find IJ, or even NB, to provide a less frustrating experience. 2012/1/16 Arnaud Héritier <aherit...@gmail.com>: > On Mon, Jan 16, 2012 at 12:34 AM, Barrie Treloar <baerr...@gmail.com> wrote: > >> 2012/1/16 Arnaud Héritier <aherit...@gmail.com>: >> > Thanks a lot for this hard wok Barrie >> > >> > yes it was my problem too Robert. >> > ITs are now very difficult to use/maintain and sadly are covering only >> the >> > fact that what we generate is always the same and not that it is working >> in >> > eclipse. >> > As far as I remember this is the larger plugin we have in lines of codes >> > and also the dirtiest one as it was built from many many contributors >> > (because of the variety of usages and eclipse versions) >> > >> > Since that, I had the chance to switch from eclipse to intellij and it >> > solved all my issues. >> >> lol. >> >> Well what black magic is intellij doing that makes using maven better? >> > > In fact my disagreement with eclipse is over than only its Maven integration > I didn't use it now for more than one year thus I cannot tell how it is > going now but my impediment was to have to choose between > * m2eclipse which supported a little subset of eclipse features (WTP > integration didn't work well before JBoss start to investigate on it, ...), > which was slow/unusable for large projects but which provided for what it > supported a good developer experience. > * maven-eclipse-plugin that had a larger set of feature but that was broken > in many points like the dependency management and its inability to import > parent/aggregators POMs. > > Nowadays I'm using IntelliJ which has a transparent integration (I just > open a Maven project) and supports large projects. I don't use anymore a > JEE integration thus I don't know if it is better or worst than eclipse > with WTP. > > >> There is the option to switch to m2e. >> I cant do that for some of my projects because they are Eclipse RCP >> 3.2 projects that are bodge anyway. >> m-e-p works well enough. >> > > Yes, it was I maintained it also. > > >> >> Its worse than you summarize because: >> * it does its own dependency analysis because there was no standard >> way of exposing that before (refactoring to use aether is an option) >> > > => yes it is just horrible. But remember why it doesn't use the native > maven dep management : it is because you want to be able to import a > project that has its dependencies (or more generally some descriptors) > broken. I think it's always no possible even with aether to have a mode > where it loads what it can. I don't remember how is the behavior of m2e or > intellij in that case. I didn't test it for a long time. > > >> * the ITs were built at the time where there was no IT standard >> > yes :( > > >> * there is support for eclipse-like environments (RAD, etc) which is >> even harder to maintain >> > yes, and like I said, ITs are almost useless because I had several times > the case that even if we continued to generate the same thing, eclipse > didn't support it after an upgrade. And sadly for all these configuration > files, there is no documentation (AFAIR) and are considered as an internal > stuff from eclipse point of view. These aren't APIs that we can rely on. > > >> * some OSGi support which is using deprecated feature sets and is >> impossible to maintain because there are no ITs or use cases for it. >> >> yes > > >> This list is probably a part of the reason that Jason suggested >> retiring plugins. >> (This one is sporadically maintained but it still works as advertised) >> >> > yes, but I'm not agree to retire it as far as we have few people like you > involved in it because it continues to be used and probably it continues to > have more users than m2eclipse > > Arnaud > > >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
