[jira] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165319#action_165319
]
John Allen edited comment on MSITE-129 at 2/12/09 12:00 PM:
Module locations (and thus links) are based upon project.distro.site.url and
project.url. They have no bearing on where a module is on the filesystem.
The structure you have drawn as 'what it should be' is stating that the
submodules inherit from myproj, which they dont. And thats why in the generated
site they dont live under it.
There are two very different namespaces here and none of them are related.
One is the filesystem. In this case your myproj and its sub dirs. This
namespace has no bearing on the URL namespace or for that matter the project
inheritance relationships.
The next is the project hierarchy. That does have a relationship to the URL
namespace, only IF, you inherit the settings for project.url and
project.distributionManagement.site.url. However if you override those at each
project level then these two are unrelated.
When a project deploys itself into the URL space, it uses its distro.site.url
to work out where it should go. This obviously needs to be related to the
project's URL otherwise it will deploy to a location that no other project will
ever be able to find by using that project's URL.
The module projects all do the same, namely deploy to locations dependent upon
their distro.site.url.
So first up, there is no relationship between the deployemnt URL location and
the filesystem structure.
A aggregator project, such as myproj generates links to its modules. These its
calculates by asking each module, what is your DEPLOYED project url. Each
project returns its URL and the aggregator project calculates the relative
paths (if possible) to the module projects from its own URL.
You did deploy the projects to check that the module links were woerking didnt
you? They will never work in an undeployed state.
was (Author: skaze):
df
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.0
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139588#action_139588
]
johanandren edited comment on MSITE-129 at 6/25/08 2:19 PM:
-
One more vote about the importance of this issue here.
We have a netbeans-platform application setup like this:
application/
---cluster1/
--module1/
--module2/
---cluster2/
--module3/
--module4/
---common-parent/
where all the maven modules ("clusters", "modules" and "application") share the
common-parent as project parent (it primarily containins dependency
management). We need to do it this way since the netbeans-maven-plugin only can
create an application from project submodules.
If we run site:site on application non-recursive ("mvn -N") this gives us a
site for application with each cluster listed as a module. When we run
site:site recursively we get a site with no modules listed at all. I'm not 100%
sure but it sounds as it is the same problem listed here.
was (Author: johanandren):
One more vote about the importance of this issue here.
We have a netbeans-platform application setup like this:
application/
cluster1/
module1/
module2/
cluster2/
module3/
module4/
common-parent/
where all the maven modules ("clusters", "modules" and "application") share the
common-parent containing dependency management. We need to do it this way since
the netbeans-maven-plugin only can create an application from project
submodules.
If we run site:site on application non-recursive ("mvn -N") this gives us a
site for application with each cluster listed as a module. When we run
site:site recursively we get a site with no modules listed at all. I'm not 100%
sure but it sounds as it is the same problem listed here.
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-8
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121582
]
skaze edited comment on MSITE-129 at 1/28/08 5:50 PM:
---
Yeah you're right, the assumption that a project's parent is its aggregator
should not be there.
was (Author: skaze):
Yeah you're right, the relation between module to parent should not be
there.
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103088
]
Matt Read edited comment on MSITE-129 at 7/24/07 5:28 AM:
--
I think the site should display both and we would certainly benefit from some
very explicit traversable documentation of both styles of pom relationships as
they both have a very significant meaning in terms of logical and physical
component and package breakdown.
However I don't think they should necessarily be related. After a fair amount
of experimentation we use pom inheritance to manage common maven build
behaviour and modules to manage common application sub-system organisation. For
example, all webapps inherit from the same base pom but these webapps may
appear in completely different module hierarchies. E.g.
Common maven behaviour via pom inheritance:
Base WAR pom
__ app1 WAR pom
__ app2 WAR pom
Base EAR pom
__ app1 EAR pom
__ app2 EAR pom
Common sub-systems via modules:
app1 pom
__ app1 WAR
__ app1 EAR
app2 pom
__ app2 WAR
__ app2 EAR
Certainly the current site plugin behaviour is not particularly compatible with
this and I'm looking forward to an out-of-the-box site generation that produces
nicely hierarchical, cross-linked navigation for reactor builds without
requiring additional manual configuration.
was:
I think the site should display both and we would certainly benefit from some
very explicit traversable documentation of both styles of pom relationships as
they both have a very significant meaning in terms of logical and physical
component and package breakdown.
However I don't think they should necessarily be related. After a fair amount
of experimentation we use pom inheritance to manage common maven build
behaviour and modules to manage common application sub-system organisation. For
example, all webapps inherit from the same base pom but these webapps may
appear in completely different module hierarchies. E.g.
Common maven behaviour via pom inheritance:
Base WAR pom
|__ app1 WAR pom
|__ app2 WAR pom
Base EAR pom
|__ app1 EAR pom
|__ app2 EAR pom
Common sub-systems via modules:
app1 pom
|__ app1 WAR
|__ app1 EAR
app2 pom
|__ app2 WAR
|__ app2 EAR
Certainly the current site plugin behaviour is not particularly compatible with
this and I'm looking forward to an out-of-the-box site generation that produces
nicely hierarchical, cross-linked navigation for reactor builds without
requiring additional manual configuration.
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103088
]
Matt Read edited comment on MSITE-129 at 7/24/07 5:28 AM:
--
I think the site should display both and we would certainly benefit from some
very explicit traversable documentation of both styles of pom relationships as
they both have a very significant meaning in terms of logical and physical
component and package breakdown.
However I don't think they should necessarily be related. After a fair amount
of experimentation we use pom inheritance to manage common maven build
behaviour and modules to manage common application sub-system organisation. For
example, all webapps inherit from the same base pom but these webapps may
appear in completely different module hierarchies. E.g.
Common maven behaviour via pom inheritance:
Base WAR pom
|__ app1 WAR pom
|__ app2 WAR pom
Base EAR pom
|__ app1 EAR pom
|__ app2 EAR pom
Common sub-systems via modules:
app1 pom
|__ app1 WAR
|__ app1 EAR
app2 pom
|__ app2 WAR
|__ app2 EAR
Certainly the current site plugin behaviour is not particularly compatible with
this and I'm looking forward to an out-of-the-box site generation that produces
nicely hierarchical, cross-linked navigation for reactor builds without
requiring additional manual configuration.
was:
I think the site should display both and we would certainly benefit from some
very explicit traversable documentation of both styles of pom relationships as
they both have a very significant meaning in terms of logical and physical
component and package breakdown.
However I don't think they should necessarily be related. After a fair amount
of experimentation we use pom inheritance to manage common maven build
behaviour and modules to manage common application sub-system organisation. For
example, all webapps inherit from the same base pom but these webapps may
appear in completely different module hierarchies. E.g.
Common maven behaviour via pom inheritance:
Base WAR pom
|__ app1 WAR pom
|__ app2 WAR pom
Base EAR pom
|__ app1 EAR pom
|__ app2 EAR pom
Common sub-systems via modules:
app1 pom
|__ app1 WAR
|__ app1 EAR
app2 pom
|__ app2 WAR
|__ app2 EAR
Certainly the current site plugin behaviour is not particularly compatible with
this and I'm looking forward to an out-of-the-box site generation that produces
nicely hierarchical, cross-linked navigation for reactor builds without
requiring additional manual configuration.
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103004
]
John Allen edited comment on MSITE-129 at 7/23/07 12:30 PM:
I'm curious should a site be displaying a project's modules or a project's
children (i.e. 'inherited from' projects)? I know I am more interested in the
later when I'm browsing sub-systems, as, as with any design effort, one divides
and conquers, layering common behaviour and semantics as you decompose. But I
would then expect those children to be part of this natural aggregated scope -
if something is a child then it is an ordered relationship with its parent and
it should be possible to view/navigate/build following those relationships in
both directions.
It's worth noting that the dual behaviour re how to find parents/modules comes
from the attempt to support generating a site for a project that has modules
and or a parent but is not running in the reactor. If one says that modules are
not children but simply an aggregation, and thus parent's can not know of their
children in a declarative way, then the only way to deduce children of a
project is to have a reactor and to re-build the inheritance hierarchy from the
the edges up, thus discovering the true project ancestry.
Without a declarative way for a parent to specify its children then the parent
site will never be able to list its children without a reactor and inferencing.
Maybe we should add a new semantic to help us here that differentiates from a
project's children (inheritance) and modules (collection)?
was:
I'm curious should a site be displaying a project's modules or a project's
children (i.e. 'inherited from' projects)? I know I am more interested in the
later when I'm browsing sub-systems, as, as with any design effort, one divides
and conquers, layering common behaviour and semantics as you decompose. But I
would then expect those children to be part of this natural aggregated scope -
if something is a child then it is an ordered relationship with its parent and
it should be possible to view/navigate/build following those relationships in
both directions.
It's worth noting that the dual behaviour re how to find parents/modules comes
the attempt to support generating a site for a project that has modules and or
a parent but is not running in the reactor. If one says that modules are not
children but simply an aggregation, and thus parent's can not know of their
children in a declarative way, then the only way to deduce children of a
project is to have a reactor and to re-build the inheritance hierarchy from the
the edges up, thus discovering the true project ancestry.
Without a declarative way for a parent to specify its children then the parent
site will never be able to list its children without a reactor and inferencing.
Maybe we should add a new semantic to help us here that differentiates from a
project's children (inheritance) and modules (collection)?
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you
