Discussion:
Plugin execution not covered by lifecycle configuration
(too old to reply)
Nord, James
2011-04-07 21:36:17 UTC
Permalink
Hi,

I'm trying the M6a Indigo and M build of M2e.

I'm hitting a major problem in that our build has many issues with plugins that have no lifecycle config in m2e.

Whilst I understand the reason for the error I am happy to ignore this I can only do it for one plugin per module at once - which means there is a tedious job of ignoring 150+ lifecycle issues.

Is there a way to ignore multiple lifecycle issues at once? (eclipse used to allow you to find related issues and fix them all with the same quick fix IIRC)

Regards,

/James


________________________________

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the ***@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
Nord, James
2011-04-07 22:52:36 UTC
Permalink
Ahh,

Found out what the quickfix was actually doing under the hood - so configured the lifecycle plugin in the top level parent pom

/James

From: m2e-users-***@eclipse.org [mailto:m2e-users-***@eclipse.org] On Behalf Of Nord, James
Sent: 07 April 2011 22:36
To: m2e-***@eclipse.org
Subject: [m2e-users] Plugin execution not covered by lifecycle configuration

Hi,

I'm trying the M6a Indigo and M build of M2e.

I'm hitting a major problem in that our build has many issues with plugins that have no lifecycle config in m2e.

Whilst I understand the reason for the error I am happy to ignore this I can only do it for one plugin per module at once - which means there is a tedious job of ignoring 150+ lifecycle issues.

Is there a way to ignore multiple lifecycle issues at once? (eclipse used to allow you to find related issues and fix them all with the same quick fix IIRC)

Regards,

/James


________________________________

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the ***@nds.com<mailto:***@nds.com> and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
Ben Tatham
2011-05-26 18:49:19 UTC
Permalink
Can someone please explain to me why we have to add all
the pluginExecutionFilters for all of the specific plugins eveywhere to work
around this problem? Why did it work in Helios without this, but in newer
Indigo versions, we have to muddle our pom's with eclipse-specific stuff?

Thank,
Ben
Ahh,
Found out what the quickfix was actually doing under the hood – so
configured the lifecycle plugin in the top level parent pom
/James
*Sent:* 07 April 2011 22:36
*Subject:* [m2e-users] Plugin execution not covered by lifecycle
configuration
Hi,
I’m trying the M6a Indigo and M build of M2e.
I’m hitting a major problem in that our build has many issues with plugins
that have no lifecycle config in m2e.
Whilst I understand the reason for the error I am happy to ignore this I
can only do it for one plugin per module at once – which means there is a
tedious job of ignoring 150+ lifecycle issues.
Is there a way to ignore multiple lifecycle issues at once? (eclipse used
to allow you to find related issues and fix them all with the same quick fix
IIRC)
Regards,
/James
------------------------------
**************************************************************************************
This message is confidential and intended only for the addressee. If you
have received this message in error, please immediately notify the
The content of e-mails as well as traffic data may be monitored by NDS for
employment and security purposes. To protect the environment please do not
print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
4EX, United Kingdom. A company registered in England and Wales. Registered
no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
--
Ben Tatham
Software Developer
Nanometrics Inc.
+1 613-592-6776 x254
http://www.nanometrics.ca
Jochen Wiedmann
2011-05-26 18:53:15 UTC
Permalink
Ben, you sound like you could at least explain what's going on? So
far, I found no explanation at all?
Post by Ben Tatham
Can someone please explain to me why we have to add all
the pluginExecutionFilters for all of the specific plugins eveywhere to work
around this problem?  Why did it work in Helios without this, but in newer
Indigo versions, we have to muddle our pom's with eclipse-specific stuff?
Thank,
Ben
Ahh,
Found out what the quickfix was actually doing under the hood – so
configured the lifecycle plugin in the top level parent pom
/James
On Behalf Of Nord, James
Sent: 07 April 2011 22:36
Subject: [m2e-users] Plugin execution not covered by lifecycle configuration
Hi,
I’m trying the M6a Indigo and M build of M2e.
I’m hitting a major problem in that our build has many issues with plugins
that have no lifecycle config in m2e.
Whilst I understand the reason for the error I am happy to ignore this I
can only do it for one plugin per module at once – which means there is a
tedious job of ignoring 150+ lifecycle issues.
Is there a way to ignore multiple lifecycle issues at once? (eclipse used
to allow you to find related issues and fix them all with the same quick fix
IIRC)
Regards,
                /James
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you
have received this message in error, please immediately notify the
content of e-mails as well as traffic data may be monitored by NDS for
employment and security purposes. To protect the environment please do not
print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
4EX, United Kingdom. A company registered in England and Wales. Registered
no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
--
Ben Tatham
Software Developer
Nanometrics Inc.
+1 613-592-6776 x254
http://www.nanometrics.ca
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
--
I Am What I Am And That's All What I Yam (Popeye)
Igor Fedorenko
2011-05-26 19:35:04 UTC
Permalink
I started to write some documentation explaining what's going on and
what to do about it at [1].

[1] http://wiki.eclipse.org/M2E_plugin_execution_not_covered

--
Regards,
Igor
Post by Ben Tatham
Can someone please explain to me why we have to add all
the pluginExecutionFilters for all of the specific plugins eveywhere to
work around this problem? Why did it work in Helios without this, but
in newer Indigo versions, we have to muddle our pom's with
eclipse-specific stuff?
Thank,
Ben
Ahh,
Found out what the quickfix was actually doing under the hood – so
configured the lifecycle plugin in the top level parent pom
/James
*Sent:* 07 April 2011 22:36
*Subject:* [m2e-users] Plugin execution not covered by lifecycle
configuration
Hi,
I’m trying the M6a Indigo and M build of M2e.
I’m hitting a major problem in that our build has many issues with
plugins that have no lifecycle config in m2e.
Whilst I understand the reason for the error I am happy to ignore
this I can only do it for one plugin per module at once – which
means there is a tedious job of ignoring 150+ lifecycle issues.
Is there a way to ignore multiple lifecycle issues at once? (eclipse
used to allow you to find related issues and fix them all with the
same quick fix IIRC)
Regards,
/James
------------------------------------------------------------------------
**************************************************************************************
This message is confidential and intended only for the addressee. If
you have received this message in error, please immediately notify
from your system as well as any copies. The content of e-mails as
well as traffic data may be monitored by NDS for employment and
security purposes. To protect the environment please do not print
this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex,
TW18 4EX, United Kingdom. A company registered in England and Wales.
Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
--
Ben Tatham
Software Developer
Nanometrics Inc.
+1 613-592-6776 x254
http://www.nanometrics.ca
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
Jochen Wiedmann
2011-05-26 20:54:23 UTC
Permalink
Thanks, Igor, for the explanation. Let me summarize, what I read from that:

Because of some "long-standing issues" and some "rogue maven plugins"
you choosed to invent a system that enforces registration of every
Maven plugin in the so-called lifecycle configuration.

Rather than assuming a meaningful default (most possibly the same that
has been in use in the past), which ensures upwards compatibility and
reduces side effects to those users that actually notice the
"long-standing issues" and or the "rogue maven pllugins" and are thus
willing to apply some explicit configuratiom, you make us all change
tons of poms that have been working perfectly well in both native
Maven and m2eclipse?

Is that it?
Post by Igor Fedorenko
I started to write some documentation explaining what's going on and
what to do about it at [1].
[1] http://wiki.eclipse.org/M2E_plugin_execution_not_covered
--
Regards,
Igor
Post by Ben Tatham
Can someone please explain to me why we have to add all
the pluginExecutionFilters for all of the specific plugins eveywhere to
work around this problem?  Why did it work in Helios without this, but
in newer Indigo versions, we have to muddle our pom's with
eclipse-specific stuff?
Thank,
Ben
   Ahh,
   Found out what the quickfix was actually doing under the hood – so
   configured the lifecycle plugin in the top level parent pom
   /James
   *Sent:* 07 April 2011 22:36
   *Subject:* [m2e-users] Plugin execution not covered by lifecycle
   configuration
   Hi,
   I’m trying the M6a Indigo and M build of M2e.
   I’m hitting a major problem in that our build has many issues with
   plugins that have no lifecycle config in m2e.
   Whilst I understand the reason for the error I am happy to ignore
   this I can only do it for one plugin per module at once – which
   means there is a tedious job of ignoring 150+ lifecycle issues.
   Is there a way to ignore multiple lifecycle issues at once? (eclipse
   used to allow you to find related issues and fix them all with the
   same quick fix IIRC)
   Regards,
                    /James
 ------------------------------------------------------------------------
 **************************************************************************************
   This message is confidential and intended only for the addressee. If
   you have received this message in error, please immediately notify
   from your system as well as any copies. The content of e-mails as
   well as traffic data may be monitored by NDS for employment and
   security purposes. To protect the environment please do not print
   this e-mail unless necessary.
   NDS Limited. Registered Office: One London Road, Staines, Middlesex,
   TW18 4EX, United Kingdom. A company registered in England and Wales.
   Registered no. 3080780. VAT no. GB 603 8808 40-00
 **************************************************************************************
   _______________________________________________
   m2e-users mailing list
   https://dev.eclipse.org/mailman/listinfo/m2e-users
--
Ben Tatham
Software Developer
Nanometrics Inc.
+1 613-592-6776 x254
http://www.nanometrics.ca
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
--
I Am What I Am And That's All What I Yam (Popeye)
Igor Fedorenko
2011-05-27 04:02:13 UTC
Permalink
Not exactly. Let me explain...

There was never a really meaningful default. What we had did not work
well or did not work at all for many projects. Probably even worse, it
not always worked for many projects, so we had to go through series of
refresh/update dependencies/update configuration/rebuild voodoo (or "m2e
dance" as some called it) to get projects in a good state. For example
MNGECLIPSE-823 [1] was the most voted issues in m2e jira and it was a
direct manifestation of this "flakiness".

The solution we came up with, when fully implemented (!), is expected to
work well for all supported projects out-of-the-box, i.e. without any
changes to pom.xml, but fail fast and gracefully for unsupported
projects, in which case the users will be able to use explicit pom.xml
configuration as a workaround. When you import one of supported projects
in m2e workspace, m2e automatically discovers and installs any
additional required software, so the project "just works" without any
changes to pom.xml.

For this to work, however, m2e needs a library of lifecycle mapping
metadata and corresponding project configurators and we hope m2e user
and adopter community will help growing and maintaining this library.
And if you are interested to help, you can start by submitting an
enhancement request m2e bugzilla. If you want to implement support for
"not covered" plugins used by your project, please join m2e-dev mailing
list and we'll be happy to provide pointers.

Of course, there is a chance we overlooked another, simpler solution, so
if you think you know how to make m2e work reliably and efficiently with
all/many projects while failing gracefully for the rest, please bring
this up on m2e-dev and I will see how is the best to schedule this.


[1] https://issues.sonatype.org/browse/MNGECLIPSE-823

--
Regards,
Igor
Post by Jochen Wiedmann
Because of some "long-standing issues" and some "rogue maven plugins"
you choosed to invent a system that enforces registration of every
Maven plugin in the so-called lifecycle configuration.
Rather than assuming a meaningful default (most possibly the same that
has been in use in the past), which ensures upwards compatibility and
reduces side effects to those users that actually notice the
"long-standing issues" and or the "rogue maven pllugins" and are thus
willing to apply some explicit configuratiom, you make us all change
tons of poms that have been working perfectly well in both native
Maven and m2eclipse?
Is that it?
Post by Igor Fedorenko
I started to write some documentation explaining what's going on and
what to do about it at [1].
[1] http://wiki.eclipse.org/M2E_plugin_execution_not_covered
--
Regards,
Igor
Post by Ben Tatham
Can someone please explain to me why we have to add all
the pluginExecutionFilters for all of the specific plugins eveywhere to
work around this problem? Why did it work in Helios without this, but
in newer Indigo versions, we have to muddle our pom's with
eclipse-specific stuff?
Thank,
Ben
Ahh,
Found out what the quickfix was actually doing under the hood – so
configured the lifecycle plugin in the top level parent pom
/James
*Sent:* 07 April 2011 22:36
*Subject:* [m2e-users] Plugin execution not covered by lifecycle
configuration
Hi,
I’m trying the M6a Indigo and M build of M2e.
I’m hitting a major problem in that our build has many issues with
plugins that have no lifecycle config in m2e.
Whilst I understand the reason for the error I am happy to ignore
this I can only do it for one plugin per module at once – which
means there is a tedious job of ignoring 150+ lifecycle issues.
Is there a way to ignore multiple lifecycle issues at once? (eclipse
used to allow you to find related issues and fix them all with the
same quick fix IIRC)
Regards,
/James
------------------------------------------------------------------------
**************************************************************************************
This message is confidential and intended only for the addressee. If
you have received this message in error, please immediately notify
from your system as well as any copies. The content of e-mails as
well as traffic data may be monitored by NDS for employment and
security purposes. To protect the environment please do not print
this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex,
TW18 4EX, United Kingdom. A company registered in England and Wales.
Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
--
Ben Tatham
Software Developer
Nanometrics Inc.
+1 613-592-6776 x254
http://www.nanometrics.ca
Jochen Wiedmann
2011-05-27 06:31:26 UTC
Permalink
Post by Igor Fedorenko
Of course, there is a chance we overlooked another, simpler solution, so
if you think you know how to make m2e work reliably and efficiently with
all/many projects while failing gracefully for the rest, please bring
this up on m2e-dev and I will see how is the best to schedule this.
For example, how about default=execute, at least while developing the
metadata library? That would, IMO, spare us this discussion and lots
of similar discussions in the near future? And, if I get things right,
we'd had not a worse state than we had before. (Which we currently do,
IMO. I struggled about one hour yesterday in the evening in trying to
get my poms working. Although there was definitely another problem in
m2e as well, which I'll report later on, so the lifecycle mapping
isn't the only thing to blame.)

Jochen
--
I Am What I Am And That's All What I Yam (Popeye)
Matthew Piggott
2011-05-27 13:39:49 UTC
Permalink
The problem with executing by default is that it also leaves some projects
in an unusable state. Either choice isn't a perfect experience for all
users (at least initially), so it was decided that m2e should take the safer
approach.
Post by Jochen Wiedmann
Post by Igor Fedorenko
Of course, there is a chance we overlooked another, simpler solution, so
if you think you know how to make m2e work reliably and efficiently with
all/many projects while failing gracefully for the rest, please bring
this up on m2e-dev and I will see how is the best to schedule this.
For example, how about default=execute, at least while developing the
metadata library? That would, IMO, spare us this discussion and lots
of similar discussions in the near future? And, if I get things right,
we'd had not a worse state than we had before. (Which we currently do,
IMO. I struggled about one hour yesterday in the evening in trying to
get my poms working. Although there was definitely another problem in
m2e as well, which I'll report later on, so the lifecycle mapping
isn't the only thing to blame.)
Jochen
--
I Am What I Am And That's All What I Yam (Popeye)
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
Igor Fedorenko
2011-05-27 13:45:45 UTC
Permalink
I wish it was that simple.

First, "execute" was not the default. m2e had none less than four
different sets of maven goals it ran during project import, project
configuration update and workspace full and incremental builds. Some of
these were configured at workspace level, some in project/.settings. On
top of that there was project-level setting to "skip"
maven-compiler-plugin execution.

Second, "execute" _is_ the root cause of missing resources, endless
builds and memory leaks, so making it the default basically blocks all
other possibilities to improve.

Also, m2e 0.13 is much better at detecting incompatibilities and
reporting them. So when 0.12 was kinda-sorta-working-sometimes, 0.13
creates those big red obvious error markers. We could hide the error
markers by default and let the users _guess_ what's going on. I don't
think there are too many projects that worked well in 0.12 and don't
work in 0.13, so most likely hiding the errors will make users feel
better about m2e 0.13 when comparing it with 0.12. At the same time I
believe failing fast and obviously is the right thing to do.

--
Regards,
Igor
Post by Jochen Wiedmann
Post by Igor Fedorenko
Of course, there is a chance we overlooked another, simpler solution, so
if you think you know how to make m2e work reliably and efficiently with
all/many projects while failing gracefully for the rest, please bring
this up on m2e-dev and I will see how is the best to schedule this.
For example, how about default=execute, at least while developing the
metadata library? That would, IMO, spare us this discussion and lots
of similar discussions in the near future? And, if I get things right,
we'd had not a worse state than we had before. (Which we currently do,
IMO. I struggled about one hour yesterday in the evening in trying to
get my poms working. Although there was definitely another problem in
m2e as well, which I'll report later on, so the lifecycle mapping
isn't the only thing to blame.)
Jochen
Ben Tatham
2011-05-27 20:46:14 UTC
Permalink
Thank you for the answers and the wiki page -- its beginning to become
clear.

However, I am still having problems. If I define multiple
lifecycle-mapping pluginExecutionFilter, and then another in a parent pom,
the effective pom only shows one of them (the first one defined in the local
pom: excluding the second and the one from the parent pom). I also get a
NullPointerException (see details below) -- which I assume might be a result
of this discrepancy in the effective pom. I couldn't find a related bug for
this...

I also attempted to add the buildhelper plugin connector which also had
NPEs.

-Ben

Errors running builder 'Maven Project Builder' on project 'apollo-taurus'.

java.lang.NullPointerException
at
org.eclipse.m2e.core.internal.lifecyclemapping.model.PluginExecutionFilter.match(PluginExecutionFilter.java:304)
at
org.eclipse.m2e.core.internal.lifecyclemapping.SimpleMappingMetadataSource.getPluginExecutionMetadata(SimpleMappingMetadataSource.java:71)
at
org.eclipse.m2e.core.internal.lifecyclemapping.LifecycleMappingFactory.calculateEffectiveLifecycleMappingMetadata(LifecycleMappingFactory.java:294)
at
org.eclipse.m2e.core.internal.lifecyclemapping.LifecycleMappingFactory.calculateEffectiveLifecycleMappingMetadata(LifecycleMappingFactory.java:208)
at
org.eclipse.m2e.core.internal.lifecyclemapping.LifecycleMappingFactory.calculateLifecycleMapping(LifecycleMappingFactory.java:159)
at
org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.setupLifecycleMapping(ProjectRegistryManager.java:526)
at
org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:445)
at
org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:327)
at
org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:278)
at
org.eclipse.m2e.core.internal.project.registry.MavenProjectManager.refresh(MavenProjectManager.java:58)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:120)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

eclipse.buildId=I20110519-1138
java.version=1.6.0_25
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_CA
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -data c:\tools\eclipse\eclipse-indigo\workspace -os
win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product
Post by Igor Fedorenko
I wish it was that simple.
First, "execute" was not the default. m2e had none less than four
different sets of maven goals it ran during project import, project
configuration update and workspace full and incremental builds. Some of
these were configured at workspace level, some in project/.settings. On
top of that there was project-level setting to "skip"
maven-compiler-plugin execution.
Second, "execute" _is_ the root cause of missing resources, endless
builds and memory leaks, so making it the default basically blocks all
other possibilities to improve.
Also, m2e 0.13 is much better at detecting incompatibilities and
reporting them. So when 0.12 was kinda-sorta-working-sometimes, 0.13
creates those big red obvious error markers. We could hide the error
markers by default and let the users _guess_ what's going on. I don't
think there are too many projects that worked well in 0.12 and don't
work in 0.13, so most likely hiding the errors will make users feel
better about m2e 0.13 when comparing it with 0.12. At the same time I
believe failing fast and obviously is the right thing to do.
--
Regards,
Igor
Post by Igor Fedorenko
Of course, there is a chance we overlooked another, simpler solution, so
Post by Igor Fedorenko
if you think you know how to make m2e work reliably and efficiently with
all/many projects while failing gracefully for the rest, please bring
this up on m2e-dev and I will see how is the best to schedule this.
For example, how about default=execute, at least while developing the
metadata library? That would, IMO, spare us this discussion and lots
of similar discussions in the near future? And, if I get things right,
we'd had not a worse state than we had before. (Which we currently do,
IMO. I struggled about one hour yesterday in the evening in trying to
get my poms working. Although there was definitely another problem in
m2e as well, which I'll report later on, so the lifecycle mapping
isn't the only thing to blame.)
Jochen
_______________________________________________
m2e-users mailing list
https://dev.eclipse.org/mailman/listinfo/m2e-users
--
Ben Tatham
Software Developer
Nanometrics Inc.
+1 613-592-6776 x254
http://www.nanometrics.ca
Jochen Wiedmann
2011-05-27 21:05:34 UTC
Permalink
Post by Igor Fedorenko
I wish it was that simple.
Igor, you know much more about the plugin than I do. But you can't
convince me that doing things this way was an unlucky decision.
Indeed, I can very easily proof my theory: Without that decision, you
wouldn't need to argue against fools like me. ;-)
--
I Am What I Am And That's All What I Yam (Popeye)
Igor Fedorenko
2011-05-28 00:16:27 UTC
Permalink
I am not sure what you mean, but I am prone to picking unnecessary
complex solutions, so if you have ideas how we can made things easier
please don't hesitate to share them. I would not be surprised if there
was a simple yet workable way to integrate maven with eclipse workspace,
we just could not think of one yet.

--
Regard,
Igor
Post by Jochen Wiedmann
Post by Igor Fedorenko
I wish it was that simple.
Igor, you know much more about the plugin than I do. But you can't
convince me that doing things this way was an unlucky decision.
Indeed, I can very easily proof my theory: Without that decision, you
wouldn't need to argue against fools like me. ;-)
Marcello Teodori
2011-06-12 17:46:57 UTC
Permalink
If the problem is just having to modify the pom.xml to give
proper directions to m2e, which is something I would also prefer
to avoid, wouldn't it be easier to have this information stored
in the m2e eclipse preferences file of the project?
It wouldn't disturb anyone and IMHO I think it would make much
more sense to have it there.
Also I fear developers not upgrading to Indigo or newer m2e
just because they're not allowed to modify their existing poms...

my 2c,
Marcello

Continue reading on narkive:
Loading...