[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-users] The mess that is M2E connectors
|
Quite possible that I'll return to that offer.
Thanks, Igor!
On Sun, Aug 28, 2011 at 4:35 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> 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
>> m2e-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/m2e-users
>
> _______________________________________________
> m2e-users mailing list
> m2e-users@xxxxxxxxxxx
> 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)
