Bugzilla – Full Text Bug Listing
| Summary: | maven overrides eclipse java compile settings. | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Richard A. Sitze <rsitze> |
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | igor, mkleint |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Richard A. Sitze
and exactly for these reasons above, I've argued for removing the "convert" action altogether a while back. Because it promises more than it delivers (or is even capable of delivering). it's not only the javac settings but any settings for that matter and having all matched and identified is an effort of gargantuan proportions and one which will only very sparsely be used. Also don't forget dependencies etc.. In terms of categorization, this is more likely an enhancement request than a bug though. (In reply to comment #1) > In terms of categorization, this is more likely an enhancement request than a > bug though. Perhaps... however it's not a one-time thing. Again, maven gives me the option of resetting the project to the maven settings ((not at work, not looking at the menus, don't have exact phrase) and it again plows over the project settings. I can SCM-revert .settings/*, .classpath, and .project files... but still. I would agree there are plenty of work arounds in place. I also feel that this is "bug" level behavior due to the fundamental "silent introduction of changes" that can & have broken eclipse's ability to "auto compile". If you're a long-time Eclipse user (such as I), and new to maven (such as I), it's non-trivial to go figure out what I need to do on the maven side. My first instinct (and my second, third, & forth - it's only recently I gave in) was to drop back and scrub maven. I'd even be happy with a Eclipse-2-Maven users guide to help me manually set Maven to match my Eclipse settings. I explored using the eclipse build system (buckminster) for a while too, in hopes that I could find a truly eclipse-friendly build system. However it too falls flat on it's face unless you're building "plugins". Thus far, m2e was mainly concerned about matching IDE configuration to what happens during command line build. Going the other way, i.e. configuring command line build based on Eclipse workspace project settings, is certainly a legitimate use case but we never got to look at it in any details. And this applies to pretty much everything aspect of project configuration, not just JDT compiler settings. I also want to stress importance of configuration *matching*, regardless if configuration goes from cli->ide or from ide->cli, both ide and cli should behave comparably at the end. Having said that, m2e development team does not have immediate plans to introduce ide->cli configuration update path in m2e. This, of course, can change if somebody puts forward plausible design and volunteers to work on the implementation. If you are interested, please share your ideas on m2e-dev mailing list. |