|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 :
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).I'll skip the rant about threats to use "alternative IDE" and about opensource development in general, so see my specific answers inline
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...-- 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 . 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.  https://bugs.eclipse.org/bugs/show_bug.cgi?id=350414
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  and m2e development team plans to fix this in m2e 1.1.  https://bugs.eclipse.org/bugs/show_bug.cgi?id=361642
Great, can't wait for it. :-)
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).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).
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
Back to the top