Community
Participate
Working Groups
m2e alters classpathentry entries in the .classpath file that are not marked as maven.pomderived. Here's an example: I have a folder named src/main/resources where I keep a couple of non-java files. The .classpath file contains the following line: <classpathentry kind="src" output="target/classes" path="src/main/resources"/> Even though this line does not have a "maven.pomderived" attribute declared, it is always changed into: <classpathentry including="**/*.java" kind="src" output="target/classes" path="src/main/resources"/> so anyone using the project in an IDE where m2e is not installed will now get errors when trying to run. I would expect m2e to leave lines that are not specifically marked with maven.pomderived="true" alone. See http://dev.eclipse.org/mhonarc/lists/m2e-users/msg03925.html for more details and background discussion.
Is there any update on this issue?
No, no update. I have no plans to look at this issue unless a quality patch is provided. I am not even decided if this is a bug or works as expected.
I could look into this but the fact that Igor haven't decided if this is a bug or not worries me. Please note that it doesn't matter if the maven.pomderived attribute is missing or if it's explicitly set to false. The entry is *always* overwritten regardless. The maven.pomderived attribute seems to be completely ignored at all times. Surely that must be a bug?
The indent of maven.pomderived=true was to enable cleanup of stale classpath entries generated based on pom.xml configuration. This is specifically explained in the javadoc, so the observed behaviour is not a bug according to javadoc. You can also see original bug 353266. What you request is to change the API to something like "m2e never touches classpath entries if pom.derived=false or not specified". I don't think I understand all consequences of such a change without trying it out. If you decide to work on a patch, the new behaviour should apply to all classpath entries, not just resources folder. There should also be new API to remove and/or modify custom classpath entries. I also think import wizard and update configuration dialog should provide a way to reset custom entries, possible a checkbox which is unchecked by default.
(In reply to Igor Fedorenko from comment #4) > ... This is specifically explained in the javadoc, so the observed behaviour > is not a bug according to javadoc. From the javadoc of setPomDerived(boolean derived): Not-derived (or custom) entries are preserved during project configuration update, while derived entries are automatically removed whenever their corresponding pom.xml configuration is changed or removed. Can you please explain to me what the difference is between "not-derived" and "custom" entries?
(In reply to Thomas Hallgren from comment #5) > (In reply to Igor Fedorenko from comment #4) > > ... This is specifically explained in the javadoc, so the observed behaviour > > is not a bug according to javadoc. > > From the javadoc of setPomDerived(boolean derived): > > Not-derived (or custom) entries are preserved during project configuration > update, while derived entries are automatically removed whenever their > corresponding pom.xml configuration is changed or removed. > > Can you please explain to me what the difference is between "not-derived" > and "custom" entries? No difference, "not-derived" and "custom" are two ways to name the same thing.
It seems this mechanism is only good for keeping non-pomderived *paths* intact, not the entries per se. The m2e generated entry will always overwrite a custom entry when there's a path conflict. I can understand the need for that approach (how else would the initial classpath be generated) but I think there's a need for something that actually do preserve custom entries in case of path conflicts (a maven.noclobber or something). That, and perhaps a clarification in the javadoc regarding the true meaning of pomderived. To me "preserve" means - do not overwrite with generated stuff.
I don't think we need new 'noclobber' attribute, just new API to remove/replace custom classpath entries and UI action to remove all custom classpath entries (during configuration update, for example).
(In reply to comment #8) > I don't think we need new 'noclobber' attribute, just new API to remove/replace > custom classpath entries and UI action to remove all custom classpath entries > (during configuration update, for example). Does this prevent that normal "update projecs" overwrite an intentionally, manually modified classpath entry, e.g. for the JRE (as needed by the tycho-p2-director-plugin module, cf. bug 439426)?
Yes, I believe m2e will overwrite manually configured JRE_CONTAINER classpath container.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
