[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-users] Long term outlook for 'M2E plugin executionnotcovered'
|
I'd like to add my 2c to the discussion, from the perspective of a
developer of a few m2e connectors.
You need to realize that writing a connector is easy. In fact it is _a
lot_ easier than writing a maven plugin that is actually useful.
You don't need to be the developer of a maven plugin to create the
connector. You don't even need to know or understand any of the plugin
internals.
What you need to know, is how to use the plugin, and how the IDE
integration should work. What files should be watched for modifications,
what files are updated by the plugin. What configuration options are
relevant. You can treat the maven plugin as a black box in very many cases.
In very many cases writing a connector is not really necessary. There
are many plugins out there that don't need to be integrated into IDE at
all, because they don't belong to the modify - save - compile - unit
test cycle. With no connectors / lifecycle mapping definition they cause
error markers on POMs but this is merely an annoyance not a loss of
function problem. Other plugins need to be run to get the project to
build correctly, but the resources they process are changed
infrequently. With no connector present, they need to be launched from
command line (followed by workspace refresh) at least once after
checking out the source from SCM. If they need to be re-launched now and
then, an external tool launcher can be created. This is sub-optimal, but
workable. Then, there comes a category of plugins that actually need to
be part of the modify - compile - test cycle and need to run frequently,
after each/most file modifications in the IDE. That's when the connector
can save the day. Luckily, majority of plugins that actually need to be
included are Java source generators, and writing connectors for those is
easy, and there are a few examples available.
Now the other part of the story. Writing the connector code is easy, but
setting up the project structure is complicated, and frustrating.
Writing the connectors was my first encounter with Tycho, and I had
virtually zero prior knowledge of Eclipse internals, OSGi and P2.
Getting all the POMs, Eclipse xml and manifest files right is not easy.
I've worked with Tycho 0.12 and also tried 0.13 SNAPSHOT builds, but due
to the problems with P2 internals, builds using explicit target platform
definition take a long time. 2 minutes turnaround times for testing even
the most trivial changes to project packaging make development
frustrating and time consuming. This, in my opinion, is the real problem
that new connector developers are facing.
The barrier to development of new connectors could be substantially
lowered through a Maven archetype that one could use to generate all the
Tycho boilerplate files. I've worked on that for a while
https://github.com/objectledge/maven-extensions/tree/master/archetypes
but I had trouble to get it right, and then I run out of steam / got
busy with other things and did not finish it... I'll bring it up on the
dev list.
Cheers,
Rafał
On 08/15/2011 01:53 AM, Joe Littlejohn wrote:
Thanks Max, Philippe& all for your thoughtful replies.
I think you've certainly described accurately the reasons for the
current direction on plugin execution. I understand the benefits in
performance and predictability that were intended. Unfortunately I
think the sacrifices that have been made to support this new direction
are too great. In my humble opinion this isn't a minor inconvenience
for users, it's a problem that fundamentally breaks relationship
between developer, build tool and IDE and jeopardises the viability of
Eclipse for many organisations and projects that use Maven. To add to
that, it also simply causes a terrible experience when arriving in
Indigo/m2e for the first time.
So it's clear that m2e _does_ require a new integration layer
('connectors') to be written across the plugin universe. I get the
impression that the plan is the tick off the obviously popular plugins
as a high priority then let the rest of the connectors slowly arrive
more organically. I think this strategy is based on a somewhat naive
view of the variety of affected Maven plugins out there. There are not
only a large number of public plugins in use, there are also many
thousands of private plugins used within organisations that, if teams
continue to use Eclipse, will need new integration work to create
connectors. There are public 'feature complete' plugins that have long
since ceased active development and no obvious owners to provide
connectors. An easier option will be to simply use another IDE that
doesn't require its own bespoke integration layer on top of Maven.
I find the idea that Maven plugin developers should be responsible for
IDE integration to be a little strange. Should a Maven plugin
developer be expected to provide integration into Eclipse, Netbeans,
IDEA, JDeveloper, etc, etc? Thankfully other IDEs aren't showing signs
of taking a similar direction to m2e - how high would the barrier to
entry for new Maven plugin developers become if they did? Please don't
underestimate how much work you've given plugin developers here,
creation and maintenance of an m2e connector along with every new
plugin is *a lot* of additional work.
For all its faults, m2eclipse managed to balance compatibility and
performance and was highly successful. I understand this is a
difficult balance to strike. Of course some plugins don't play nice
with m2eclipse, but what we need is simple, gradual refinements that
improve the experience. The way that m2eclipse understood the
MavenProject and changes made to it meant that for most development
teams, m2eclipse was simple, effective and super-compatible. In
comparison, m2e is only vaguely fit for purpose as it no longer
integrates with Maven as designed (a highly pluggable build tool), at
least not for an alarmingly popular set of use-cases.
So I expect developers in my organisation may stick to Helios +
m2eclipse 0.12 for the time being. I truly hope that in a future
Eclipse release train the m2e development team will rethink this.
As for arguments about where m2e config belongs, since when was adding
a new file to SCM a problem? The pom is a universal artifact that
should be compatible with any IDE. Does anyone else see any irony in
the fact that m2e now (in some circumstances) has big problems with
plugins it doesn't recognise, yet at the same time it expects users to
fill their pom files with an Eclipse specific plugin configuration?
On 13 August 2011 22:01, Philippe Bastiani
<philippe.bastiani@xxxxxxxxxxx> wrote:
Yes, the developer of a Maven plugin should be responsible for its
integration into a given IDE... Delegate the setting of the IDE to the
end-user is the worst solution ... This is what was proposed with
maven-eclipse-plugin.
I agree with you for the following point: I do not understand why the
connectors requires modification of poms. I do not understand why Sonatype
does not offer an API for saving the settings of connectors in another file.
Jason and Igor could, I think, explain this choice !
_______________________________________________
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
