[
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: l...@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
