Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 2.1
-
Fix Version/s: 2.2
-
Labels:None
-
Environment:Any
-
Number of attachments :
Description
I have several projects which are structured as follows:
.../myproject/myproject
.../myproject/myproject-module1
.../myproject/myproject-module2
In the above ".../myproject" refers to the top level directory under which all of the project's modules are stored. "/myproject/myproject" is the parent module, and "/myproject/myproject-module1" and "/myproject/myproject-module2" are child modules of that parent.
After upgrading to Maven 2.0.7, mvn idea:idea no longer creates the IPR file (/myproject/myproject/myproject.ipr) correctly. Instead of referencing "/myproject/myproject-module1/myproject-module1.iml" and "/myproject/myproject-module2/myproject-module2.iml" for the child modules, it references "/myproject/module1/myproject-module1.iml" and "/myproject/module2/myproject-module2.iml." Notice what has happened here-the "myproject" prefix has been stripped from the relative paths to the child modules.
I believe that the cause of this lies in AbstractIdeaMojo.java, method toRelative(). It is attempting to determine whether "absolutePath" lies under "basedir" in the directory structure. It does this by verifying that absolutePath starts with basedir, and if so, checking whether absolutePath is longer than basedir. If so, it chops basedir from the beginning of absolutePath and uses the result as the relative module path. Here is the code:
if ( absolutePath.startsWith( basedir.getAbsolutePath() )
&& absolutePath.length() > basedir.getAbsolutePath().length() )
I do not believe that this logic is quite what is intended. It will match both in the situation where the child project is located under the basedir, AND where the child project's name starts with the parent project's name. I think the former case is what is intended; the latter is not. In other words, the following errantly match:
basedir: ".../myproject/myproject"
absolutePath: ".../myproject/myproject-module1/myproject-module1.iml"
Note that, given the "if" condition above, these match...but it does not mean that absolutePath refers to a subdirectory in basedir. I think the fix for this issue would involve something like such, to ensure that "relative" really does refer to a subdirectory of basedir on return:
if ( absolutePath.startsWith( basedir.getAbsolutePath() + File.separator )
&& absolutePath.length() > basedir.getAbsolutePath().length() )
{ relative = absolutePath.substring( basedir.getAbsolutePath().length() + 1 ); }
We're now only matching if absolutePath starts with basedir as a directory name. This is done by appending the directory separator to the basedir string before doing the check. I have not had the opportunity to test this yet, but the fix will be something at least close to that.
An interim workaround is to rename the parent project to something like "myproject-parent", which makes it no longer a "starts with" substring of "myproject-module1".
I hope I have conveyed the problem/solution adequately. It's kind of tough to put words on it. 
The attached patch seems to satisfy all of the existing test cases, and it also works for our "parent in sibling directory" layout. Unfortunately I was unable to complete a test for this because the following line in AbstractIdeaTestCase.java requires that the .ipr file end up in the top project directory:
File outputFile = new File( PlexusTestCase.getBasedir(), "target/test-harness/" + testCounter +
"/plugin-test-" + testCounter + "." + targetExtension );
Since the whole point of this patch is to move the parent project to a subdirectory of the parent directory, it will always fail the assertion that immediately follows it:
assertTrue( "Target file was created", outputFile.exists() );
Aside from that, I do have a working test case. I just don't want to twiddle around with AbstractIdeaTestCase too much in order to make it work--I figure that somebody more familiar with the codebase should handle that.