You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "John Allen (JIRA)" <ji...@codehaus.org> on 2008/11/25 17:03:19 UTC

[jira] Created: (MSHARED-83) populateModulesMenuItemsFromReactorProjects logic is incorrect, a module does not have to be a child

populateModulesMenuItemsFromReactorProjects logic is incorrect, a module does not have to be a child
----------------------------------------------------------------------------------------------------

                 Key: MSHARED-83
                 URL: http://jira.codehaus.org/browse/MSHARED-83
             Project: Maven Shared Components
          Issue Type: Bug
          Components: maven-doxia-tools
    Affects Versions: maven-doxia-tools 1.0.1
            Reporter: John Allen


Some of this is my fauilt as the code in question came from some of  the patch wsork i did on 2.0-beta-6.

Basically populateModulesMenuItemsFromReactorProjects uses the following to determine if a project in the reactor is a module of the current project:

{code}
                if ( reactorProject != null && reactorProject.getParent() != null
                    && project.getArtifactId().equals( reactorProject.getParent().getArtifactId() ) )
{code}

This is invalid. A module != child

This needs to be changed to a check that's based upon the project's location, for that's all we've got when it comes to determining the backref relationship of a module to its aggregator (the enclosing project that refered to the module via a <module> element.

Patch will follow



-- 
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] Commented: (MSHARED-83) populateModulesMenuItemsFromReactorProjects logic is incorrect, a module does not have to be a child

Posted by "John Allen (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MSHARED-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155380#action_155380 ] 

John Allen commented on MSHARED-83:
-----------------------------------

Having a closer look I also see that the old bug where multiple parent menus are populated becuase the call to 

{code}
        populateProjectParentMenu( decorationModel, locale, project, project, true );
{code}

is being called in the recursive getDecorationModel() rather than at the same place as the call to populateModules()

patch fixes this so project's only get one parent menu entry and not all the parent's in the hierarchy.



> populateModulesMenuItemsFromReactorProjects logic is incorrect, a module does not have to be a child
> ----------------------------------------------------------------------------------------------------
>
>                 Key: MSHARED-83
>                 URL: http://jira.codehaus.org/browse/MSHARED-83
>             Project: Maven Shared Components
>          Issue Type: Bug
>          Components: maven-doxia-tools
>    Affects Versions: maven-doxia-tools 1.0.1
>            Reporter: John Allen
>
> Some of this is my fauilt as the code in question came from some of  the patch wsork i did on 2.0-beta-6.
> Basically populateModulesMenuItemsFromReactorProjects uses the following to determine if a project in the reactor is a module of the current project:
> {code}
>                 if ( reactorProject != null && reactorProject.getParent() != null
>                     && project.getArtifactId().equals( reactorProject.getParent().getArtifactId() ) )
> {code}
> This is invalid. A module != child
> This needs to be changed to a check that's based upon the project's location, for that's all we've got when it comes to determining the backref relationship of a module to its aggregator (the enclosing project that refered to the module via a <module> element.
> Patch will follow

-- 
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: (MSHARED-83) populateModulesMenuItemsFromReactorProjects logic is incorrect, a module does not have to be a child

Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MSHARED-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Lundberg closed MSHARED-83.
----------------------------------

       Resolution: Fixed
    Fix Version/s: maven-doxia-tools 1.0.2

Patch applied with minor modifications to follow our code style. Thanks a lot John.

> populateModulesMenuItemsFromReactorProjects logic is incorrect, a module does not have to be a child
> ----------------------------------------------------------------------------------------------------
>
>                 Key: MSHARED-83
>                 URL: http://jira.codehaus.org/browse/MSHARED-83
>             Project: Maven Shared Components
>          Issue Type: Bug
>          Components: maven-doxia-tools
>    Affects Versions: maven-doxia-tools 1.0.1
>            Reporter: John Allen
>            Assignee: Dennis Lundberg
>             Fix For: maven-doxia-tools 1.0.2
>
>         Attachments: 1.0.1-modules-patch.diff
>
>
> Some of this is my fauilt as the code in question came from some of  the patch wsork i did on 2.0-beta-6.
> Basically populateModulesMenuItemsFromReactorProjects uses the following to determine if a project in the reactor is a module of the current project:
> {code}
>                 if ( reactorProject != null && reactorProject.getParent() != null
>                     && project.getArtifactId().equals( reactorProject.getParent().getArtifactId() ) )
> {code}
> This is invalid. A module != child
> This needs to be changed to a check that's based upon the project's location, for that's all we've got when it comes to determining the backref relationship of a module to its aggregator (the enclosing project that refered to the module via a <module> element.
> Patch will follow

-- 
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: (MSHARED-83) populateModulesMenuItemsFromReactorProjects logic is incorrect, a module does not have to be a child

Posted by "John Allen (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MSHARED-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Allen updated MSHARED-83:
------------------------------

    Attachment: 1.0.1-modules-patch.diff

addresses the repeated <parents> menu items bug that results in all parents appearing in the parents menu
addresses the incorrect <modules> menu logic where modules are assumed to inherit from parents. modules != children

> populateModulesMenuItemsFromReactorProjects logic is incorrect, a module does not have to be a child
> ----------------------------------------------------------------------------------------------------
>
>                 Key: MSHARED-83
>                 URL: http://jira.codehaus.org/browse/MSHARED-83
>             Project: Maven Shared Components
>          Issue Type: Bug
>          Components: maven-doxia-tools
>    Affects Versions: maven-doxia-tools 1.0.1
>            Reporter: John Allen
>         Attachments: 1.0.1-modules-patch.diff
>
>
> Some of this is my fauilt as the code in question came from some of  the patch wsork i did on 2.0-beta-6.
> Basically populateModulesMenuItemsFromReactorProjects uses the following to determine if a project in the reactor is a module of the current project:
> {code}
>                 if ( reactorProject != null && reactorProject.getParent() != null
>                     && project.getArtifactId().equals( reactorProject.getParent().getArtifactId() ) )
> {code}
> This is invalid. A module != child
> This needs to be changed to a check that's based upon the project's location, for that's all we've got when it comes to determining the backref relationship of a module to its aggregator (the enclosing project that refered to the module via a <module> element.
> Patch will follow

-- 
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