Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 361824

Summary: Regression[MNGECLIPSE-767]Path must include project and resource name: /
Product: z_Archived Reporter: Stephen Davidson <steve>
Component: m2eAssignee: Project Inbox <m2e.core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: igor, lucas, steve
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard: stalebug
Attachments:
Description Flags
Patch for the product (m2e) that solves the exception described in the bug
none
Test case that verifies the patch
none
A more complete test case in a patch for the test repo none

Description Stephen Davidson CLA 2011-10-24 11:50:33 EDT
Build Identifier: 20110916-0149

This appears to be a regression on [MNGECLIPSE-767](http://jira.codehaus.org/browse/MNGECLIPSE-767).  Setting a build target outside of the Eclipse workspace is again resulting in an almost identical StackTrace as defined in the original bug (almost == a few line numbers are off here and there by 1 in the stack trace).  Unfortunately, this feature is required for some versions of Source Code control.

Installed components:
m2e: Maven Integration for Eclipse
version: 1.0.100.20110804-1717

Maven Integration for WTP
version: 0.14.0.20110928-2045

m2e connector for mavenarchiver pom properties
version: 0.15.0.201109290002

Embedded Maven Runtime 3.0.3
version: 1.0.1.201106291304


Reproducible: Always

Steps to Reproduce:
1. In Settings.xml
      <properties>
      	<user.build.dir>C:/builds</user.build.dir>
      </properties>

2. In a (child) project pom.xml
         <directory>${user.build.dir}/${project.groupId}/${parent.artifactId}/${project.artifactId}</directory>

3. Build Project.
java.lang.IllegalArgumentException: Path must include project and resource name: /
Comment 1 Igor Fedorenko CLA 2011-11-07 13:25:58 EST
There are no plans to support project build directory outside of ${project.basedir} but I am open for discussion of the best way to communicate this to the user.
Comment 2 Lucas Persson CLA 2013-09-17 09:06:55 EDT
Created attachment 235566 [details]
Patch for the product (m2e) that solves the exception described in the bug
Comment 3 Lucas Persson CLA 2013-09-17 09:07:51 EDT
Created attachment 235567 [details]
Test case that verifies the patch

This patch is for the test repository.
Comment 4 Igor Fedorenko CLA 2013-09-17 09:21:44 EDT
plan to review the patch some time this week
Comment 5 Igor Fedorenko CLA 2013-09-21 18:26:42 EDT
The test does not appear to be testing anything relevant. If I run "mvn clean integration-test -Puts,its,osx" the test passes even though it runs with unpatched m2e. (you don't need osx profile on linux and I don't know if tests run on windows).
Comment 6 Lucas Persson CLA 2013-09-24 11:18:04 EDT
Created attachment 235768 [details]
A more complete test case in a patch for the test repo

This time I the test case will break on an unpatched product.

I had to test to add test class path using the class path provider.

The test should really also throw exception on configurationManager.updateProjectConfiguration(project, monitor); when an unlatched product is used. But that only happen when running inside a real Eclipse. Maybe my test env which is using the read only file system is the real root issue but looking at the code I do not think so.

Cheers
Lucas
Comment 7 Igor Fedorenko CLA 2013-09-25 09:56:39 EDT
I can see what you are trying to test, but the test needs more work. Simply counting runtime classpath entries is not a reliable way to verify expected project build output directory location.

In addition to runtime classpath, the test needs to verify compile classpath. You can use org.eclipse.m2e.jdt.internal.ClasspathDescriptor to access project compile classpath or use IJavaProject#getRawClasspath directly.

For both runtime and compile classpath, the test needs to verify expected output location, which is currently /tmp/test361824_targetFolderOutsideBasedir/test361824_targetFolderOutsideBasedir/target/classes and /tmp/test361824_targetFolderOutsideBasedir/test361824_targetFolderOutsideBasedir/target/test-classes if I am not mistaken. (hopefully, this will also include fixes to the main code ;-) )

When you attach updated patches, please mark the old patches as obsolete.
Comment 8 Lucas Persson CLA 2013-09-25 10:57:37 EDT
It actually seems that she I run the integration tests the the output folder turnouts to be /test361824_targetFolderOutsideBasedir/tmp/test361824_targetFolderOutsideBasedir/test361824_targetFolderOutsideBasedir/target/classes but running the plugin inside a real Eclipse installation like Eclipse for JEE developers version 4.3 then the output folder will be /tmp/test361824_targetFolderOutsideBasedir/test361824_targetFolderOutsideBasedir/target/classes


Also in the real product running unlatch then configurationManager.updateProjectConfiguration(project, monitor); throws exception but the running the integration tests on an unpatched set of plugins will not result in exception.

It seems that the Eclipse core libs for finding resource in a project works differently in the integration test setup compare to the real Eclipse product.
Comment 9 Igor Fedorenko CLA 2013-09-29 09:24:46 EDT
I don't know where the problem is, but the provided test case does not validate expected m2e behaviour and I will not accept this contribution unless this is addressed.
Comment 10 Lucas Persson CLA 2013-09-29 12:18:40 EDT
Yeah I understands that.
But then perhaps you can tell me what are the difference in the tests setup compared to running the "real" Eclipse product? To me it looks like when running the "real" Eclipse product Eclipse is enforcing additional sanity tests which the test setup lacks.
Comment 11 Igor Fedorenko CLA 2013-09-29 12:22:34 EDT
Difference in current work directory is the only thing I can think of, but this is just a guess, I don't really know. Generally, I am not aware of significant discrepancies between test and real environments.
Comment 12 Eclipse Genie CLA 2014-12-04 13:25:33 EST
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.
Comment 13 Denis Roy CLA 2021-04-19 13:24:30 EDT
Moved to https://github.com/eclipse-m2e/m2e-core/issues/