[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-users] Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (execution: default-compile, phase: compile)
|
Le 4/11/2011 11:06, Igor Fedorenko a écrit :
I'll skip the rant about threats to use "alternative IDE" and about
opensource development in general, so see my specific answers inline
Ok sorry that you felt this as threat, it is just that the current
behaviour makes my Eclipse bearly-usable because the errors reported by
m2e hide all the other errors I have (my project contains 66 projects,
and it is really just not possible to open all 66 projects all the time
to check if there is no other errors in them besides the ones reported
by m2e).
--
Regards,
Igor
On 11-11-03 5:24 PM, Guillaume Polet wrote:
m2e developers, I appreciate your work and do not want you to feel
attacked in any way on this, but just want to suggest that you should
maybe consider this as a more important issue than it is currently. And
my belief is that there are cheap and simple solutions that could make a
lot of people a lot happier.
1) From what I read, many people are upset by having to reconfigure
their pom just for m2e, ... and even more upset to see that the m2e team
considers this as a minor issue.
Lifecycle configuration in pom.xml is tracked as [1]. m2e development
team does not have immediate plans to implement this feature for the
reasons I explained in the bugzila but we will accept a quality patch
that implements this feature. I will be happy to provide more detailed
requirements for the "quality" patch on m2e-dev mailing list.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=350414
If it is not too complex to get its hands in m2e code and Eclipse stuff,
I would be glad to help provide "quality" patch. My idea is to have a
constructive behaviour, not to trash someone else's work.
I have checked out the code and managed to import all Maven projects. If
you can provide me a few pointers on where to look in the code (and
possibly, if you have one in your hand, a good documentation link), I
should be able to work on that. Waiting for your input to continue on
this subject...
2) Quite some people would already be very happy to simply see those
errors as warning (including myself). It could be a setting if you
really feel this is an error, but IMHO, we lived without this error for
years, so I don't really understand the need to report these problems as
a strong issue with an error marker (especially that we cannot fix this
same error on all projects with the quick fix assistant). I don't think
that this must be something terribly complicated to modify nor very
impacting in your code, so this could easily be done and would already
make many people happy.
Please open an enhancement request to make severity of lifecycle mapping
problems configurable with a UI preference or however else you think is
reasonable. As with storing lifecycle mapping configuration outside of
pom.xml, m2e development team has no plans to implement this but we will
accept a quality patch.
See comment above.
The fact that ignore quick-fix is not enabled for a very few maven
plugins is a bug. It is tacked as [2] and m2e development team plans to
fix this in m2e 1.1.
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=361642
Great, can't wait for it. :-)
3) The argument that "/POMs are shared across teams through Maven
repositories and through SCMs. Eclipse settings are not./ " is
contradictary in itself. If Eclipse settings are not shared it is
because they are specific to Eclipse--> Therefore, specific Eclipse
settings (like the m2e lifecycle configuration) should not be put in
shared files.
The argument is not about sharing .settings files but about
configuration inheritance. Vast majority of Maven projects are
multi-module. Lifecycle mapping configuration stored outside of pom.xml
will result in significant duplication of configuration, will be tedious
to setup, difficult to maintain and, at the end, not many users will
actual use it. This is why we do not see this feature as a good
investment of the limited resources we have, but as I mentioned above
we will accept a quality patch (which, btw, is not a trivial amount of
work in itself).
I do not deny that lifecycle mapping configuration is an easy thing to
do, and I do know too that open source development resources are scarce
(I am myself working on an opensource project).
I don't claim either that this should be ignored and go back to the old
M2Eclipse way where indeed some behaviour could be very random. I am
just saying that the current approach also causes some drastic issues
(but maybe there is a better hope to fix them).
Cheers,
Guillaume
Just to let you how serious I think this is, I am really considering
moving to an alternate IDE just for that. May sound stupid, but other
IDE do not go through these kind of ugly patch, so I really don't see
why Eclipse should.
Sorry if you feel this is harsh, this is not my intent.
Cheers,
Guillaume
Le 2/11/2011 13:33, Vegard B. Havdal a écrit :
On Nov 2, 2011, at 12:52 PM, Rafał Krzewski wrote:
get it preinstalled in their Eclipse when they start working on a
project, and everything will be fine. All the scary error markers
will go away :)
They mask out other ones in the Package Explorer and Problems panes.
If there were a way to turn it into a warning, as a workspace
setting, that alone would've solved this issue for me. Anyone? :)
Vegard
_______________________________________________
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
_______________________________________________
m2e-users mailing list
m2e-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-users
