Community
Participate
Working Groups
In a pom.xml reference I get an error saying: Unable to parse configuration of mojo org.apache.maven.plugins:maven-resources-plugin:2.5:copy-resources for parameter directory: Error evaluating the expression '${project.parent.basedir}/test' for onfiguration value 'directory' (org.apache.maven.plugins:maven-resources-plugin:2.5:copy-resources:default:process-test-resources) <plugin> <artifactId>maven-resources-plugin</artifactId> <executions> <execution> <phase>process-test-resources</phase> <goals> <goal>copy-resources</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/test-classes</outputDirectory> <resources> <resource> <directory>${project.parent.basedir}/test</directory> <includes> <include>*.properties</include> </includes> </resource> </resources> </configuration> </execution> </executions> </plugin> I am not looking for eclipse to honor these additional source path inclusions but to instead just properly parse the associated property ${project.parent.basedir}
Created attachment 195510 [details] Sample project with associated issue I am using the nightly of m2e core attached is a sample project that will show the error inside Eclipse on the associated property mentioned.
This problem still appears with m2e 1.1. The problem here is that m2e issues an error where no error exists: The configuration given in the example works fine in regular maven. And there are good reasons to use this kind of configuration. We also use it in a complicated multi-module build. Having false error messages pop up in Eclise is quite annoying with a common policy to have an error-free workspace before a check-in is allowed. Since this is an error on the m2e side, potential solutions could be (in order of preference): 1) The m2e core is enhanced to understand this kind of syntax. 2) The severity of this "error" is downgraded to info. 3) A configuration option to allow to disable "unable to parse configuration" messages.
It seems that this an intentional design decision from m2e, which seems to me rather strange: https://bugs.eclipse.org/bugs/show_bug.cgi?id=344080#c2
Indeed, as I said in https://bugs.eclipse.org/bugs/show_bug.cgi?id=344080#c2 all project resources must be contained under project basedir. This largely a limitation of Eclipse Workspace, which makea it hard/impossible to implement correct incremental build behaviour for such cross-project resource references. Having said that, I am a sucker for a quality patch, so if somebody can provide a good working implementation (along with regression tests, of course) I'll be more than happy to admit I was wrong.
Thanks for the info. So Eclipse does not support this feature of Maven. I can understand that a real fix could be very complicated, then. However, my proposition of "The severity of this "error" is downgraded to info." seems to be easy to implement and would also fix this bug. Without any fix the problem still remains that the error m2e gives is still incorrect, which will confuse users.
The errors indicate an actual problem, i.e. the project is not (fully) compatible with m2e. m2e has no way of knowing if the problem is relevant to your project or can be safely ignored.
In pseudocode (I have no idea of the Eclipse API): if expression evaluation path partof subfolder of current Eclipse project then trow new error message "Error evaluating the expression" else throw new info message "M2E cannot evaluate this expression" Otherwise, option 3) "A configuration option to allow to disable "unable to parse configuration" messages." also fixes this. If m2e cannot distinguish this, the user surely can. Implementation wise seems to be simple. There's already a GUI in the m2e configuration to hide some other warnings. Just for my understanding if this stays on WONTFIX: m2e is not striving to be 100% Maven compatible?
WONTFIX == this is a problem, but we have no immediate plans to fix it. Please provide a quality patch and I will reconsider.
Igor, I know this discussion is moot, but just for the fun :-) Of course you're the developer so you can decide and act as you wish. I don't even know if you get paid for your work And of course, I can create a patch for this. I just need to download the whole source, setup the build process, learn some new APIs of which I don't know anything about, create a patch, submit it to you and hope for the best you'll accept it. I'm guessing with my experience this would take me a week. Or, you could add a trivial option to the GUI, which would take you maybe 2 hours. I'd be even willing to drop you some money if that would be any help. In the end it's your product that is broken, not mine. I'm busy fixing my own product (which is also broken much too often ;-). Keep on coding, I still appreciate all the work being done in m2e. Until now ;-)
To keep the fun going... m2e is broken for you, it works perfectly fine for me and very large number of other users. And I am not even sure "broken" is the right word to describe your situation here. If it was truly broken for you, I somehow think you'd be far motivated to spend your time into actual fix. And this is the key for me -- if a problem is not bad enough for somebody to invest into solving it, then the problem can be ignored.
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
