[
http://jira.codehaus.org/browse/MIDEA-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Jensen updated MIDEA-103:
------------------------------
Attachment: AbstractIdeaMojo.java.patch
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.
> Incorrect module paths are generated when parent project name is prefix in
> child project names
> ----------------------------------------------------------------------------------------------
>
> Key: MIDEA-103
> URL: http://jira.codehaus.org/browse/MIDEA-103
> Project: Maven 2.x IDEA Plugin
> Issue Type: Bug
> Affects Versions: 2.1
> Environment: Any
> Reporter: Matt Jensen
> Priority: Minor
> Attachments: AbstractIdeaMojo.java.patch
>
>
> 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() )
> {
> relative = absolutePath.substring(
> basedir.getAbsolutePath().length() + 1 );
> }
> 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. :-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
