Quite possible that I'll return to that offer. Thanks, Igor!
On Sun, Aug 28, 2011 at 4:35 AM, Igor Fedorenko <[email protected]> wrote: > m2e core is quite modular. It should be possible to implement what you > suggest (i.e. run maven goals at some point of eclipse project > configuration and build) using existing m2e extensions APIs. > I strongly recommend you work on such implementation and I promise to > review and accept reasonable patches to m2e core that make this > implementation easier (provided these patches meet m2e quality > standards, of course). > > -- > Regards, > Igor > > On 11-08-27 8:52 PM, Jochen Wiedmann wrote: >> >> Hi, >> >> just like to point your attention to >> >> http://grumpyapache.blogspot.com/2011/08/mess-that-is-m2e-connectors.html >> >> It should be better to read there, but I am quoting for the sake of >> discussion below: >> >> >> The mess that is m2e connectors >> >> Warning: The following is most likely stubborn, >> unreasonable,one-sided, and ignores a lot of facts, of which I am >> unaware. >> >> I am an Eclipse user since approximately 10 years. I am also a user of >> Maven 2 since may be 4-5 years. As a consequence I am also using the >> former M2Eclipse (an Eclipse Plugin for using Maven as the Eclipse >> Builder) since its early days. While I am quite happy with Eclipse and >> Maven, the experience with M2Eclipse has never been free from >> annoyance and fights. To be honest, it has always been hard to >> convince my colleagues to use it. And I fear that battle is lost now. >> I wasn't the one loosing it: The decisive strike was administrated by >> M2E itself... >> >> M2Eclipse has recently been moved to the Eclipse Foundation. It is now >> called M2E, lives at eclipse.org and can be installed from within >> Eclipse Indigo as a standard plugin, just like CDT, or WTP, which is, >> of course, a good thing. >> >> So, when Indigo was published (together with M2E 1.0 as a simultaneous >> release), I rushed to load it down in the hope of a better user >> experience. But the first thing I noted was: M2E was showing errors in >> practically every POM I have ever written, and there are quite a few >> of them, including those of several Apache projects and those at work. >> So,as a first warning: >> >> M2E 1.0 is incompatible with its predecessors. If you want to carry on >> using it without problems, don't upgrade to Indigo, or try using an >> older version of M2Eclipse with it (I haven't tried, whether that >> works. The reason for this intentional incompatibility (!) are the >> so-calles M2E connectors, which, I am sure, have driven a lot of >> people to madness since their invention. In >> whathttp://www.blogger.com/img/blank.gif follows I'll try to outline >> my understanding of what the connectors are and why I do consider them >> a real, bloody mess. >> >> I am still not completely sure, what problem the connectors ought to >> solve, but from my past experiences I guess something like this: >> >> M2E allows you to run Maven manually. You can invoke a goal like "mcn >> install" from within Eclipse just as you would do it from the command >> line. That works (and always worked) just fine. Unfortunately, Maven >> is also invoked automagically from M2E whenever Eclipse builds the >> project, for example after a clean. In such cases M2E acts as an >> "Eclipse Builder". It is these latter invocations that people have >> always had problems withand that the connectors should hanle better. >> First of all, what are these problems? >> >> Builders can be invoked quite frequently. If automatic builds are >> enabled and you are saving after every 10 keys presse, the builders >> can be invoked every 20 seconds or so. >> The UI is mainly locked while a builder is running. In conjunction >> with the frequent invocation that means that the UI can be locked 80% >> of the time, ehich a human developer considers extremely painful, in >> particular, if the builder invokes Maven, which can take quite some >> time. >> Some Maven (I am unaware of any in reality, but the M2E developers >> are mentioning this quite frequently)plugins assume that they are >> invoked from the command line. That means, in particular, that >> System.exit is called once Maven is done. Consequently, they consider >> use of resources as unproblematic: They acquire a lot, including >> memory and don't release it properly. The resources are released >> automatically by System.exit. But that doesn't work in M2E which runs >> as long as Eclipse does (meaning the whole day for Joe Average >> Developer) and invokes Maven (and the plugin with it) again and again. >> M2E doesn't know whether a plugin (or, more precisely, a plugins >> goal) should run as part of an automatic build. For example, source >> and resource generators typicallyshould, artifact generetors typically >> should not. Consequently, a lot of unnnecessary plugins are invoked by >> the automatic build, slowing bdown the builder even more, while >> necessary goals are not. This is not what people expect and leads to >> invalid behaviour on the side of the developer. For exsmple, I keep >> telling my colleagues again and again that they shouldd invoke Maven >> manually, if the test suite depends on a generated property file. >> >> But how should connectors fix this: I am partially speculating here, >> but my impression is this: When Maven is invoked as a builder, then it >> is modified by M2E to no longer invoke plugins directly. Instead, >> Maven invokes the plugins connector, which in turn invokes the plugin. >> The connector ought to know the plugin and decide, whether a goal must >> be invoked as part of the automatic build process or not. But that >> means, in particular: >> >> M2E can invoke a plugin as part of the automatic build process if, and >> only if, there is a connector for the plugin, or you specially >> xonfigure the plugin. (More on that configuration later on.) >> >> And that is the main problem we are currently facing: Connectors are >> missing for a lot of important plugins, for example the JAXB plugins, >> the JavaCC plugins, the antrun plugin, and so on. The philosophy of >> the M2E developers seems to be that time will cure thi s problem, >> which is why they are mainly ignoring it.See, for example, >> bug 350414, bug 347521, bug 350810, bug 350811, bug 352494, bug >> 350299, and so on. Since my first attempts with Indigo, I am unaware >> of any new connectors, although the lack of them is currently the >> biggest issue that most people have with M2E. Try a Google search for >> "m2e mailing list connector", if you don't believe me. >> >> But even, if the developers werw right, they choose to completely >> ignore another problem: You can no longer use your own plugins in the >> Eclipse automatic builds, unless you create a connector for the >> plugin, or create a project-specific configuration. (Again, more on >> that confuguration in due time.) >> >> At this point, one might argue: If you have written a plugin, it >> shouldn't be too difficult or too much work to write a connector as >> well. I'LL handle that aspect below. >> >> First of all, regarding the configuration: Absent a suitable >> connector, there is currently only one possibility to use a plugin as >> part of the automatic build: You need to add a plugin-specific >> configuration snippet ike the following to your POM: >> >> >> <plugin> >> <groupid>org.eclipse.m2e</groupid> >> <artifactid>lifecycle-mapping</artifactid> >> <version>1.0.0</version> >> <configuration> >> <ifecyclemappingmetadata> >> <pluginexecutions> >> <pluginexecution> >> <pluginexecutionfilter> >> <groupid>org.codehaus.mojo</groupid> >> <artifactid>javacc-maven-plugin</artifactid> >> <versionrange>[2.6,)</versionrange> >> <goals> >> <goal>javacc</goal> >> </goals> >> </pluginexecutionfilter> >> <action> >> <execute></execute> >> </action> >> </pluginexecution> >> </pluginexecutions> >> </lifecyclemappingmetadata> >> </configuration> >> </plugin> >> >> >> >> Neat, isn't it? And so short! This would advice M2E that I want the >> javacc-maven-plugin to run as a part of the automatic M2E build. >> >> So far, I have tried to be as unbiased as posssible, but now to the >> points that drive me sick. (As if that were currently required...) >> >> The space required for the M2E configuration typically exceeds the >> actual plugin configuration by far! If there ever was a good example >> of POM pollution, here's a better one. >> M2E insists in the presence of such configuration, regardless of >> whether I want the plugin to run or not.If it is missing, then the >> automatic builder won't work at all. There is no default handling, as >> was present in previous versions of M2E. (I won't discuss what the >> default should be, I'd just like to have any.) >> The M2E configuration must be stored in the POM, or any parent >> POM. There is no other possibility, like the Eclipse preferences or >> some file in .settings. In other words, if you are using IDEA or >> NetBeans, but there is a single project member using Eclipsd, you >> still have to enjoy the M2E configuration in the POM. As bug 350414 >> shows, there are a real lot of people who consider this, at best, >> ugly. >> I tried to play nice and start creating connectors. But this >> simply didn't work: I am a Maven developer, not an Eclipse developer. >> And a connector is an Eclipse plugin. I'm not interested in writing >> Eclipse plugins. (Which Maven developer is?) But there is nothing like >> a template peoject or the like, only this well meant Wiki article, >> which doesn't help too much. For example, it assumes the use of Tycho, >> which only serves to make Eclipse programming even more complicated. >> Thedesign of the connectors looks broken to me. Have a look at the >> AbstractJavaProjectConfigurator, which seems to be the typical >> superclass of a connector: It contains methods for configuring the >> Maven classpath, for adding source folders, for creating a list of >> files that have been created (or must be refreshed): These are all >> things that are directly duplicating the work of the Maven plugin and >> should be left to the Maven plugin, or Maven, alone. In other words: >> Circumventing the Maven plugin is bad. Deciding whether to run or >> not should be left to the plugin, or Maven. (See, for example, the >> comment on "short-cutting" code generation on the Wiki page on writing >> connectors >> .) >> >> >> To sum it all up: >> >> I fail to see why we can't throw away the whole connector mess and >> replace it with a configurable Maven goal that should be run by the >> automatic build ? There is even a reasoable default: "mvn >> generate-resources". Let's reiterate the reasons for inventing >> connectors from above and compare it with this solution: >> >> Maven wouldn 't be invoked more frequently >> If a single Maven execution takes too long, fix the plugins that >> don't do a good job at detecting whether they can short-cut. Ant still >> does a better job here, years after the invention of Maven 2. >> If some plugins don't behave well with regard to resources, >> fix'em. If we can e´wait months or years for connectors, we might as >> well wait for bug fixes in plugins. >> The question whether to run a plugin or not can be left to the >> Maven lifecycle, if we choose a lifecycle goal like >> "generate-resources" Maven knows perfectly well the plugins and goals >> to include or exclude. >> _______________________________________________ >> 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 > -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) _______________________________________________ m2e-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/m2e-users
