maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lennart Jörelid (JIRA) <j...@codehaus.org>
Subject [jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
Date Tue, 18 Dec 2012 07:53:14 GMT

    [ https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315861#comment-315861
] 

Lennart Jörelid edited comment on MSITE-669 at 12/18/12 1:51 AM:
-----------------------------------------------------------------

I attached images to clarify two things:

# The reactor build structure (module definitions). This is how I believe the navigation within
the site:stage should work (and - until recently - the way I believed it *did* work).
#* Illustrated in image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby glueing together
the build reactor. Such projects do not produce anything worth deploying - other than potential
documentation which should be part of the {{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well as documentation
in the form of a maven site. These project artifacts would be deployed to a repo in a normal
manner as well as part of a compound/staged site.
# The project dependencies including inclusions. 
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the earlier/incorrect
of the two versions, as I cannot due to lacking privileges].
#* The reactor structure/projects briefly explained (to alleviate any confusion):
#*# *Codestyle* := contains rules for checkstyle, enforcer, PMD etc. This is essentially the
implementation of the developer guidelines.
#*# *Tools-parent* := defines the build reactor, including dependency management settings.
The plugins use configuration/rules from the codestyle project, implying that the tools-parent
project include codestyle as a dependency. Therefore, tools-parent is built after codestyle.
#*# *Validation-api* := defines the API of a globally available aspect. It defines the tools-parent
as parent project, to use the build cycle/codestyle rules defined within tools-parent.
#*# *Validation-aspect* := defines the globally available aspect implementation, depending
on the validation-api and using the tools-parent as parent project (to use the build cycle/codestyle
rules defined within tools-parent).
#*# *Parent* := configures AspectJ to use the aspect implementation from validation-aspect.
This makes the validation-aspect globally available to all projects using the parent project
as ... well ... parent. 

Comments and thoughts on the above:

# It seems too invasive to require parent poms (i.e. tools-parent, parent) to define modules
just to acquire a staged site with working navigation. These projects *should* be leaves,
because they may be used as parents by poms outside of the nazgul_tools reactor.
# It is practical to make all of the projects illustrated above be part of a single reactor,
since they are released as a unit - and should be documented as a unit. I suggest that the
{{site:stage}} should support this scenario.
# The structure I would expect from the {{site:stage}} command for the nazgul_tools reactor,
would match the reactor closely in terms of links/navigation. The desired/expected structure
of the {{site:stage}}-generated site is identical to the one illustrated in the image _nazgul_tools_reactor_structure_
above.
                
      was (Author: lj@jguru.se):
    I attached two images to clarify

# The reactor build structure (module definitions). This is how I believe the navigation within
the site:stage should work (and - until recently - the way I believed it *did* work).
#* Illustrated in image _nazgul_tools_reactor_structure_
#* White pom-type reactor projects only define modules and sites, thereby glueing together
the build reactor. Such projects do not produce anything worth deploying - other than potential
documentation which should be part of the {{site:stage}}.
#* Yellow jar/bundle-type projects define a single deployable artifact, as well as documentation
in the form of a maven site. These project artifacts would be deployed to a repo in a normal
manner as well as part of a compound/staged site.
# The project dependencies including inclusions. 
#* Illustrated by image _nazgul_tools_project_dependencies_. [Please remove the earlier/incorrect
of the two versions, as I cannot due to lacking privileges].
#* The reactor structure/projects briefly explained (to alleviate any confusion):
#*# *Codestyle* := contains rules for checkstyle, enforcer, PMD etc. This is essentially the
implementation of the developer guidelines.
#*# *Tools-parent* := defines the build reactor, including dependency management settings.
The plugins use configuration/rules from the codestyle project, implying that the tools-parent
project include codestyle as a dependency. Therefore, tools-parent is built after codestyle.
#*# *Validation-api* := defines the API of a globally available aspect. It defines the tools-parent
as parent project, to use the build cycle/codestyle rules defined within tools-parent.
#*# *Validation-aspect* := defines the globally available aspect implementation, depending
on the validation-api and using the tools-parent as parent project (to use the build cycle/codestyle
rules defined within tools-parent).
#*# *Parent* := configures AspectJ to use the aspect implementation from validation-aspect.
This makes the validation-aspect globally available to all projects using the parent project
as ... well ... parent. 

Comments:

# It seems too invasive to require parent poms (i.e. tools-parent, parent) to define modules
just to acquire a staged site with working navigation. These projects *should* be leaves,
because they may be used as parents by poms outside of the nazgul_tools reactor.
# It is practical to make all of the projects illustrated above be part of a single reactor,
since they are released as a unit - and should be documented as a unit. I suggest that the
{{site:stage}} should support this scenario.
# The structure I would expect from the {{site:stage}} command for the nazgul_tools reactor,
would match the reactor closely in terms of links/navigation. The desired/expected structure
of the {{site:stage}}-generated site is identical to the one illustrated in the image _nazgul_tools_reactor_structure_
above.
                  
> site:stage creates incorrect structure when module paths contains sets of "../"
> -------------------------------------------------------------------------------
>
>                 Key: MSITE-669
>                 URL: https://jira.codehaus.org/browse/MSITE-669
>             Project: Maven 2.x and 3.x Site Plugin
>          Issue Type: Bug
>          Components: multi module, relative links, site:stage(-deploy)
>    Affects Versions: 3.1, 3.2
>            Reporter: Lennart Jörelid
>            Assignee: Lukas Theussl
>         Attachments: nazgul_tools_project_dependencies.png, nazgul_tools_project_dependencies.png,
nazgul_tools_reactor_structure.png, sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets of maps relative
to the staging directory - i.e. outside of the target directory.
> {code:xml} 
> <modules>
>   <module>../../validation/validation-api</module>
>   <module>../../validation/validation-aspect</module>
>   <module>../parent</module>
> </modules>
> {code}
> The staged site should be fully included within the staging directory. It would appear
that relativization of links for site:stage should take special links into consideration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message