| Summary: | Regression[MNGECLIPSE-767]Path must include project and resource name: / | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Stephen Davidson <steve> | ||||||||
| Component: | m2e | Assignee: | 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
Stephen Davidson
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.
Created attachment 235566 [details]
Patch for the product (m2e) that solves the exception described in the bug
Created attachment 235567 [details]
Test case that verifies the patch
This patch is for the test repository.
plan to review the patch some time this week 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). 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
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. 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. 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. 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. 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. 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. |