You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Matt Jensen (JIRA)" <ji...@codehaus.org> on 2007/08/08 17:47:13 UTC
[jira] Created: (MIDEA-103) Incorrect module paths are generated
when parent project name is prefix in child project names
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
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
[jira] Updated: (MIDEA-103) Incorrect module paths are generated
when parent project name is prefix in child project names
Posted by "Matt Jensen (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Closed: (MIDEA-103) Incorrect module paths are generated
when parent project name is prefix in child project names
Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MIDEA-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Lundberg closed MIDEA-103.
---------------------------------
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.2
Fixed in r678718.
New SNAPSHOT deployed: maven-idea-plugin-2.2-20080722.112900-8
> 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
> Assignee: Dennis Lundberg
> Priority: Minor
> Fix For: 2.2
>
> 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