[jira] Commented: (MSITE-594) release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects
[
https://jira.codehaus.org/browse/MSITE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272022#comment-272022
]
John Allen commented on MSITE-594:
--
Although it has been a while a quick re-reading of my original description
would indicate that the issue does lie with the release:deploy mojo as it is
directly manipulating the various URLS of the project it is trying to deploy
before calling upon another plugins to carry out their function. It is thus the
responsibility of the deploy mojo to do this properly for all required fields
for the delegated plugins to work properly
I.e. when considering if this is or isnt in the realm of the deploy plugin to
address, consider:
It works fine and as designed when not being called by release:deploy
It doesnt work when being called by release:deploy
> release:stage does not properly compute new distroManagement.site.URL or
> project.URLs for projects
> --
>
> Key: MSITE-594
> URL: https://jira.codehaus.org/browse/MSITE-594
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
>Reporter: John Allen
>Priority: Blocker
>
> In the case where you have a multi-module project and each module has its own
> distributionManagement.site.url which is common with projects that like their
> sites to be version numbered (see example beolw) the release:stage plugin
> fails to get the project's site properly deployed. From a brief look it seems
> release:sxtage is only computing a new URL for the owning project and not all
> the child projects. What's more it looks like its changing the site
> deployment URL and not the project's corresponding project URL. This results
> in the site deployment for children going to their original pom.xml specific
> locations regardless of them being 'staged' (i.e. they're not staged, they've
> just gone live!). Nearly as bad is that all the relative links for connecting
> modules and parents and banners together are broken too, as they are based
> upoin the project.URL which hasnt been touched by the release:stage mojo.
> site:stage makes a better fist of this, basically you need to remap the
> entire URL domain (site distro and project url) to be under some other parent
> space for you to successfully stage sites (see site:stage)
> This kind of mistake has come up in the past, simply put a project can define
> all its own settings for everything so anything that makes assumptions based
> on inheritence or 'defaults' is just gonna break the system.
> Example of how sub-project's defining their own site deployemtn and project
> URL information:
> {noformat}
>
>
> dav:https://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}
>
> http://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}/
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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=165421#action_165421
]
John Allen commented on MSITE-129:
--
module != child
> 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=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] Commented: (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 commented on MSITE-129:
--
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] Commented: (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=157111#action_157111
]
John Allen commented on MSITE-129:
--
Modules should be modules and not children? Fixed in patch attached to
MSHARED-83
> 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] Commented: (MSITE-136) when inheriting site.xml the expands to a menu with links for *all* ancestors and not just the immediate parent
[ http://jira.codehaus.org/browse/MSITE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157110#action_157110 ] John Allen commented on MSITE-136: -- Patch for this is in MSHARED-83 > when inheriting site.xml the expands to a menu with links > for *all* ancestors and not just the immediate parent > --- > > Key: MSITE-136 > URL: http://jira.codehaus.org/browse/MSITE-136 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-5 > Environment: 2.0.4 >Reporter: John Allen > Fix For: 2.0-beta-8 > > > multi-project environment; root project provides site.xml > root/sub1/sub2/sub3/sub4 site pages get rendered with parent menu containing > links for all the ancestors and not just the immediate sub3 parent. > copying root's site.xml into sub4 results in parent being correctly rendered. > did not test the results of copying site.xml into the middle of the ancestry > so cant say whether the parents list starts at the project that defines the > site.xml -- 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: (MSITE-163) The modules menu is not inherited if the parent project has no modules of its own
[ http://jira.codehaus.org/browse/MSITE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157109#action_157109 ] John Allen commented on MSITE-163: -- Worth seeing MSHARED-83 too. > The modules menu is not inherited if the parent project has no modules of its > own > - > > Key: MSITE-163 > URL: http://jira.codehaus.org/browse/MSITE-163 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-4 > Environment: ubuntu linux / debian linux >Reporter: Andrew Williams > Fix For: 2.0-beta-8 > > > if I have a site.xml in a parent project that contains the line ref="modules" inherit="top" /> it is not inherited by child projects. > works, as does parent. > This happens when the parent project has no modules of its own. -- 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: (MSITE-358) site.xml urls are not always correct
[
http://jira.codehaus.org/browse/MSITE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157108#action_157108
]
John Allen commented on MSITE-358:
--
Over enthusiatsic application or resolveRelativeLinks, probably in
assembleInheritance. However the same 'issue' applies to and parent
URLs. relatives URLs are used where ever possible so that you can stage a
collection of projects together and they will link to each other but eventually
you'll hit a parent say that you've not staged but, if you were deploying to
the real location, would be available via a relative, and that link will
therefore be invalid in your staged environment.
I presume you're refering to site:stage in this.
I note in the banners those are full URLs and not relatives. What if they were
relatives? If my parent site.xml defined that it uses .,/images/foo what should
the child have for those resource locations? Is it true that the it will be
using the same skin? it may be inherting the parent's site.xml but it could it
not be using its own skin that does not contain that specifc image? Is multiple
inheritence of skins allowed or does the child's skin override the parents? If
its the later then what resource indicator is correct for an image that only
exists in the parent?
I expect just not changing them to relatives would best.
> site.xml urls are not always correct
>
>
> Key: MSITE-358
> URL: http://jira.codehaus.org/browse/MSITE-358
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: Brian Fox
>Priority: Blocker
> Fix For: 2.0-beta-8
>
>
> This is so completely broken that it must be fixed before another release
> occurs.
> The maven-parent site.xml defines some images as:
> {noformat}
>
> ${project.name}
> http://maven.apache.org/images/apache-maven-project-2.png
> http://maven.apache.org/
>
>
> http://maven.apache.org/images/maven-logo-2.gif
>
> {noformat}
> The site plugin somewhere along the line replaces these urls with ../../
> repeated based on how far down the inheritence tree you are from
> maven-parent. This means you can't stage or deploy a site to a different
> location than the maven-parent because all urls will point back to
> maven-parent's /images. Worse, every module has its own copy of the css and
> images so there's no reason for it to depend on the parent at all.
--
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] Created: (MRELEASE-395) release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects
release:stage does not properly compute new distroManagement.site.URL or
project.URLs for projects
--
Key: MRELEASE-395
URL: http://jira.codehaus.org/browse/MRELEASE-395
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-8
Reporter: John Allen
Priority: Blocker
In the case where you have a multi-module project and each module has its own
distributionManagement.site.url which is common with projects that like their
sites to be version numbered (see example beolw) the release:stage plugin fails
to get the project's site properly deployed. From a brief look it seems
release:sxtage is only computing a new URL for the owning project and not all
the child projects. What's more it looks like its changing the site deployment
URL and not the project's corresponding project URL. This results in the site
deployment for children going to their original pom.xml specific locations
regardless of them being 'staged' (i.e. they're not staged, they've just gone
live!). Nearly as bad is that all the relative links for connecting modules and
parents and banners together are broken too, as they are based upoin the
project.URL which hasnt been touched by the release:stage mojo. site:stage
makes a better fist of this, basically you need to remap the entire URL domain
(site distro and project url) to be under some other parent space for you to
successfully stage sites (see site:stage)
This kind of mistake has come up in the past, simply put a project can define
all its own settings for everything so anything that makes assumptions based on
inheritence or 'defaults' is just gonna break the system.
Example of how sub-project's defining their own site deployemtn and project URL
information:
{noformat}
dav:https://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}
http://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}/
{noformat}
--
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
[
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 menu items bug that results in all parents
appearing in the parents menu
addresses the incorrect 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 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
[
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 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] 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 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: (MCHANGELOG-87) Wrong svn path if artifactid != directory
[
http://jira.codehaus.org/browse/MCHANGELOG-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155155#action_155155
]
John Allen commented on MCHANGELOG-87:
--
there a quite a few situations where maven assumes the artifact name does equal
the svn dir name. trying to break that convention leads to problems in
construction, as you've found out. work around is to either name them to match
or to declare manually in every project.
> Wrong svn path if artifactid != directory
> -
>
> Key: MCHANGELOG-87
> URL: http://jira.codehaus.org/browse/MCHANGELOG-87
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: windows, Subversion 1.5
>Reporter: Kuno Baeriswyl
>
> site generate fails, since artifactId and directory name are not equal
> (project-foo != project_foo) :
> [INFO] Executing: svn --non-interactive log -v -r "{2008-09-22 14:39:55
> +}:{2008-10-23 14:39:55 +}" http://$repo$/trunk/sub1/project-foo
> [INFO] Working directory: d:\maven-projects\bats-upgrade\sub1\project_foo
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: '/mcs/bats-upgrade/!svn/bc/18337/trunk/sub1/project-foo' path
> not found
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error has occurred during
> changelog command :
> Command failed.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 28 seconds
> [INFO] Finished at: Wed Oct 22 16:39:56 CEST 2008
> [INFO] Final Memory: 35M/512M
> [INFO]
>
--
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] Created: (DOXIASITETOOLS-9) PathDescriptor fails to create proper absolute paths from relative components, as expected by DefaultDecorationModelInheritanceAssembler.convertPaths
PathDescriptor fails to create proper absolute paths from relative components,
as expected by DefaultDecorationModelInheritanceAssembler.convertPaths
-
Key: DOXIASITETOOLS-9
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-9
Project: Maven Doxia Site Tools
Issue Type: Bug
Affects Versions: 1.0-alpha-10
Environment: 2.0.8
Reporter: John Allen
PathDescriptor is either incorrectly implemented for handling the building of
URLs from relativePaths.
A call to
{code}
PathDescriptor( new URL(
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
), "../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png" )
{code}
And you boil down to this call
{code}
private static final URL buildUrl( final URL baseUrl, final String path )
throws MalformedURLException
{
if ( baseUrl == null )
{
throw new MalformedURLException( "Base is null!" );
}
if ( path == null )
{
return baseUrl;
}
if ( baseUrl.getProtocol().equals( "file" ) )
{
return new File( baseUrl.getFile(), path ).toURL();
}
if ( path.startsWith( "/" ) && baseUrl.getPath().endsWith( "/" ) )
{
return new URL( baseUrl, path.substring( 1 ) );
}
return new URL( baseUrl, path );
}
{code}
And critically the last line, namely:
{code}
return new URL( baseUrl, path );
{code}
where baseUrl is the previously mentioned LHS and path is the RHS passed into
the constructor
Javadoc for this baby says (java.net.URL.URL(URL context, String spec)):
{quote}
Otherwise, the path is treated as a relative path and is appended to the
context path, as described in RFC2396. Also, in this case, the path is
canonicalized through the removal of directory changes made by occurences of
".." and ".".
For a more detailed description of URL parsing, refer to RFC2396.
{quote}
Going to RFC 2396 and we find this in relation to "5.2. Resolving Relative
References to Absolute Form"
{quote}
6) If this step is reached, then we are resolving a relative-path
reference. The relative path needs to be merged with the base
URI's path. Although there are many ways to do this, we will
describe a simple method using a separate string buffer.
a) All but the last segment of the base URI's path component is
copied to the buffer. In other words, any characters after the
last (right-most) slash character, if any, are excluded.
{quote}
So what happens? First of all the most right hand side path segment of the
context is removed.
That turns our LHS url from:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
to:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins
And now it says we cat on the spec, handling the '..' etc.
So we now do this:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins
+ ../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
Which results in:
http://projects.apt.fs.fujitsu.com/com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
Which is *INVALID* as it does not exist
What this object was trying to do was create a new URL of the form:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1
+ ../../../com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
i.e.:
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt/apt-core/2/apt-core/images/banner-lhs.png
Which it can't as the first thing java.net.URL.URL(URL context, String spec)
does is strip the most right hand side segment from the context URL because it
expects it to be a resource, such as foo.jpg.
This bug was found during site creation, where we try and assemble the
descriptor using inherited site.xmls that have banners in them; the original
LHS input URL used in this description (or URL context if you prefer) comes
from the project.getURL() in AbstractSiteRenderingMojo.getDecorationModel
{code}
assembler.assembleModelInheritance( project.getName(),
decoration, parent, project.getUrl(),
parentProject.getUrl() ==
null ? project.getUrl() : parentProject
.getUrl()
{code}
And I've not seen many projects use explicit URLs of the sort
http://projects.apt.fs.fujitsu.com/apt-core/com.fujitsu.fs.apt.maven.plugins/maven-apache-plugins/1/index.html
rather the convention seems to be use the path form, rather than the full index
URL. i.e.:
htt
[jira] Commented: (MSITE-276) Links on Modules are completely broken on site:stage
[ http://jira.codehaus.org/browse/MSITE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121592 ] John Allen commented on MSITE-276: -- stage does seem to now have difficulties since beta-6 > Links on Modules are completely broken on site:stage > > > Key: MSITE-276 > URL: http://jira.codehaus.org/browse/MSITE-276 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Jörg Hohwiller > > The latest maven-site-plugin 2.0-beta-6 seems to to introduce a new bug that > was NOT present in 2.0-beta-5: > Now all my modules point to the same url which is > "../../opt/project/build/development/projects/../dummyhost.de" > Something goes very wrong here: > 1. The link should not contain pathnames specific for the environment where > it was build (/opt/project/build/development/projects) nor the hostname and > path of the distributionManagement. > 2. The modulename itself is totally lost and all module-links in the menu > have the same href > Whatever has happend here, made it a lot worse. The site is now totally > unuseable. > It seems that only mvn site was tested before the 2.0-beta-6 was released. > Multimodule-Builds need to be tested with site:stage or site:deploy. -- 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: (MSITE-236) multi module reporting - main page doesn't show links to contained modules
[ http://jira.codehaus.org/browse/MSITE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121591 ] John Allen commented on MSITE-236: -- dup of other 'empty modules menu'? > multi module reporting - main page doesn't show links to contained modules > -- > > Key: MSITE-236 > URL: http://jira.codehaus.org/browse/MSITE-236 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Reporter: Jan Vissers > > In a multi module project, the "site" generates a main page index.html, which > has the contained modules on the upper left hand corner in bold face. These > should be hyperlinks to the actual module's index.html -- 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: (MSITE-275) site:stage for multimodule project creates wrong links
[
http://jira.codehaus.org/browse/MSITE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121587
]
John Allen commented on MSITE-275:
--
We also experience this, the new relative link processing done in beta-6 doesnt
work with stage
> site:stage for multimodule project creates wrong links
> ---
>
> Key: MSITE-275
> URL: http://jira.codehaus.org/browse/MSITE-275
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-6
> Environment: Debian testing,maven 2.0.8
>Reporter: Roman Kitko
>
> For multimodule project when I exec 'mvn site:stage
> -DstagingDirectory=MY_STAGING_DIR', created links in index.html are hardcoded
> with path to project dir :
> href="../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOT">vpda-common
> When I exec mvn site", then index.html in target/site is correctly generated.
> There is workaround : use site-deploy and specify some property that is
> resolved in pom.xml as your deploy site url :
> mvn site-deploy -Dvpda.deployUrlSite=file:///home/rki/tmp/XXX
> My site.xml :
>
>
> View providers driven applications
> images/vpda.jpg
> http://vpda.org/
>
>
>
>
> http://maven.apache.org/"/>
>
>
>
>
>
>href="../${project.artifactId}-${project.version}.zip"/>
>
>
>
>
>
>
>
--
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: (MSITE-209) populateModulesMenu() logic results in invalid modules list if projects share artifactIds
[
http://jira.codehaus.org/browse/MSITE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121586
]
John Allen commented on MSITE-209:
--
This is now defunct, modules identification should no longer have any bearing
on who their parent is. See MSITE-129
> populateModulesMenu() logic results in invalid modules list if projects share
> artifactIds
> -
>
> Key: MSITE-209
> URL: http://jira.codehaus.org/browse/MSITE-209
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0-beta-6
>Reporter: John Allen
>Priority: Critical
> Attachments: site-patch.diff, site-patch.diff
>
>
> populateModulesMenu() logic should compare groupIds as well as artifactIds.
> Failure to do so can result in invalid modules list being generated when the
> reactorProject.getParent().getArtifectId() is the same as the current project
> but is not of the same group. Logic should be (dont have the code available
> as its on my laptop), oh go on then Ill HTTP the source
> private void populateModulesMenuItemsFromReactorProjects( Menu menu )
> {
> [SNIP]
> if ( reactorProject != null && reactorProject.getParent() !=
> null &&
> project.getArtifactId().equals(
> reactorProject.getParent().getArtifactId() ) )
> {
> String reactorUrl = reactorProject.getUrl();
> String name = reactorProject.getName();
> appendMenuItem( menu, name, reactorUrl,
> reactorProject.getArtifactId() );
> }
> }
> }
> }
> Comparison should also check that the groupId of the reactorProject's parent
> matches our groupId.
> Clear?.. Sorry, the patch on my laptop too...
--
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: (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_121583
]
John Allen commented on MSITE-129:
--
It's not a difficult fix, detection of the modules uses reactor or filesystem
and uses each module's basedir to match against the declared in the
aggregator project (i.e. the one we're processing), will checkout out the
beta-6 code and apply the change we've done locally to generate a patch.
> 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_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] Commented: (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
]
John Allen commented on MSITE-129:
--
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] Commented: (MSITE-136) when inheriting site.xml the expands to a menu with links for *all* ancestors and not just the immediate parent
[ http://jira.codehaus.org/browse/MSITE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121581 ] John Allen commented on MSITE-136: -- I ended up moving this out and making changes to attach-descriptor too, see MSITE-135 > when inheriting site.xml the expands to a menu with links > for *all* ancestors and not just the immediate parent > --- > > Key: MSITE-136 > URL: http://jira.codehaus.org/browse/MSITE-136 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-5 > Environment: 2.0.4 >Reporter: John Allen > Fix For: 2.0-beta-7 > > > multi-project environment; root project provides site.xml > root/sub1/sub2/sub3/sub4 site pages get rendered with parent menu containing > links for all the ancestors and not just the immediate sub3 parent. > copying root's site.xml into sub4 results in parent being correctly rendered. > did not test the results of copying site.xml into the middle of the ancestry > so cant say whether the parents list starts at the project that defines the > site.xml -- 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: (MSITE-135) inherited site.xml files are interpolated with the originating project's model values and not the consumer project's values
[
http://jira.codehaus.org/browse/MSITE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121579
]
John Allen commented on MSITE-135:
--
In regards to the multiple parent items appearing in the final leaf site, as a
quick hack I have removed the populateParentMenu and populateModulesMenu calls
from attach-descriptor mojo that resulted in the deployed site.xml being
modified before attachment and moved the populateParentMenu from within the
recursive getDecorationModel to its caller so we now only ever get one parent
item in each project's site. Wasnt the menu::inheritedRef stuff supposed to
handle all this?
> inherited site.xml files are interpolated with the originating project's
> model values and not the consumer project's values
> ---
>
> Key: MSITE-135
> URL: http://jira.codehaus.org/browse/MSITE-135
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.0-beta-5
> Environment: 2.0.4
>Reporter: John Allen
> Fix For: 2.0-beta-7
>
>
> inherited site.xml files are interpolated with the originating project's
> model values and not the consumer project's values
> i have a n-deep multiproject env; when a sub-project uses the root project's
> site.xml file, any ${project.*} expressions defined in the root site.xml are
> replaced with values from the root project and not the project that is being
> rendered, ie. title in index.html would be "root project" and not
> "sub-sub-sub-project". This applied to all ${project.*} expressions in the
> site.xml
--
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: (MSITE-163) site modules menu does not inherit
[ http://jira.codehaus.org/browse/MSITE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121580 ] John Allen commented on MSITE-163: -- This may be due to change (incorrect now in IMHO) that stated a module must inherit from its parent. I say may as I would have to check the trunk > site modules menu does not inherit > -- > > Key: MSITE-163 > URL: http://jira.codehaus.org/browse/MSITE-163 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-4 > Environment: ubuntu linux / debian linux >Reporter: Andrew Williams > Fix For: 2.0-beta-7 > > > if I have a site.xml in a parent project that contains the line ref="modules" inherit="top" /> it is not inherited by child projects. > works, as does parent. > This happens when the parent project has no modules of its own. -- 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121577 ] skaze edited comment on MRELEASE-261 at 1/28/08 5:35 PM: -- Subclipse plugin for Eclipse can not handle nested projects in Eclipse at all, and from the dialogue on their list, do not intend to. As Subversive provides much better support for nested Subversion structures in Eclipse, and has since become the 'official' (or so I'm informed) Eclipse foundation Subversion plugin, we have moved to using Subversive and find that the Eclipse multi-project import-export plugin works pretty well. Note the impact analysis for the work of changing the release plugin to be more 'directory aware' was pretty good, 3 days would have it cracked I would expect (inc. ITs etc) was (Author: skaze): Subclipse plugin for Eclipse can not handle nested projects in Eclipse at all, and from that dialogue on their list, do not intend to. As Subversive provides much better support for nested Subversion structures in Eclipse, and has since become the 'official' (or so I'm informed) Eclipse foundation Subversion plugin, we have moved to using Subversive and find that the Eclipse multi-project import-export plugin works pretty well. Note the impact analysis for the work of changing the release plugin to be more 'directory aware' was pretty good, 3 days would have it cracked I would expect (inc. ITs etc) > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: linux / maven2 / svn >Reporter: [EMAIL PROTECTED] > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121577 ] John Allen commented on MRELEASE-261: - Subclipse plugin for Eclipse can not handle nested projects in Eclipse at all, and from that dialogue on their list, do not intend to. As Subversive provides much better support for nested Subversion structures in Eclipse, and has since become the 'official' (or so I'm informed) Eclipse foundation Subversion plugin, we have moved to using Subversive and find that the Eclipse multi-project import-export plugin works pretty well. Note the impact analysis for the work of changing the release plugin to be more 'directory aware' was pretty good, 3 days would have it cracked I would expect (inc. ITs etc) > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: linux / maven2 / svn >Reporter: [EMAIL PROTECTED] > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (MINVOKER-23) Use project.getProperties() when performing IT pom interpolations
[
http://jira.codehaus.org/browse/MINVOKER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Allen updated MINVOKER-23:
---
Attachment: MINVOKER-23.diff
patch is based off 1.1 tag
> Use project.getProperties() when performing IT pom interpolations
> -
>
> Key: MINVOKER-23
> URL: http://jira.codehaus.org/browse/MINVOKER-23
> Project: Maven 2.x Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: John Allen
>Assignee: John Casey
> Attachments: MINVOKER-23.diff
>
>
> Although some excellent work has been to allow for various scheme of
> interpolation to be employed it would be very beneficial if the
> buildInterpolatedPomFile method also would use, optionally if you wish, the
> project's own properties and not just the supplied
> parameter values.
> Simple use case:
> Using the [maven-component-it-plugin to inject the project's local
> repository|https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-component-it-plugin]
> path into the project's main properties would then allow us to use this
> value to build a simple 'local repository as a main repository'
> into the IT plugin POMS which would allow us to greatly speed up testing.
> The [assembly
> plugin|https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/pom.xml]
> currently jumps through the hoops of filtering and installing a special IT
> parent pom project to interpolate this 'local repo property value' into a POM
> and then the IT poms use this parent and thus have access to the special
> repository of the form:
>
>
> main.local.as.remote
> file://${local.repo.path}
>
>
>
>
> main.local.as.remote
> file://${local.repo.path}
>
>
> If the invoker was willing to use the main project's Properties as well as
> the explicitly defined in interpolation we could
> remove the need for this filtering and installing and simply get the job done
> from in one simple call.
--
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: (MINVOKER-22) Add feature to install plugin to a local repository.
[ http://jira.codehaus.org/browse/MINVOKER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118945 ] skaze edited comment on MINVOKER-22 at 1/6/08 2:56 PM: We use the maven-component-it-plugin for this but see [Brett's comparison matrix|http://www.nabble.com/More-on-plugin-integration-testing-td14503424s177.html#a14503424] of all he different testing plugins/harnesses and approaches. Also see the codehaus 'shitty' plugin (yes that's its name) that does attempt to unify invoker and install/component-it-plugin functionality. was (Author: skaze): We use the maven-component-it-plugin for this but see Brett's comparison matrix of all he different testing plugins/harnesses and approaches. Also see the codehaus 'shitty' plugin (yes that's its name) does attempt to unify invoker and install/component-it-plugin functionality > Add feature to install plugin to a local repository. > > > Key: MINVOKER-22 > URL: http://jira.codehaus.org/browse/MINVOKER-22 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Paul Gier > Fix For: 1.2 > > > Currently if I want to test a maven plugin, I have to use the install plugin > to install the jar into a temporary repository location. It would be helpful > if there was a way that the invoker plugin could do this by itself instead of > needing to use the install plugin. -- 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: (MINVOKER-22) Add feature to install plugin to a local repository.
[ http://jira.codehaus.org/browse/MINVOKER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118945 ] John Allen commented on MINVOKER-22: We use the maven-component-it-plugin for this but see Brett's comparison matrix of all he different testing plugins/harnesses and approaches. Also see the codehaus 'shitty' plugin (yes that's its name) does attempt to unify invoker and install/component-it-plugin functionality > Add feature to install plugin to a local repository. > > > Key: MINVOKER-22 > URL: http://jira.codehaus.org/browse/MINVOKER-22 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Paul Gier > Fix For: 1.2 > > > Currently if I want to test a maven plugin, I have to use the install plugin > to install the jar into a temporary repository location. It would be helpful > if there was a way that the invoker plugin could do this by itself instead of > needing to use the install plugin. -- 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] Created: (MINVOKER-23) Use project.getProperties() when performing IT pom interpolations
Use project.getProperties() when performing IT pom interpolations
-
Key: MINVOKER-23
URL: http://jira.codehaus.org/browse/MINVOKER-23
Project: Maven 2.x Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.1
Reporter: John Allen
Assignee: John Casey
Although some excellent work has been to allow for various scheme of
interpolation to be employed it would be very beneficial if the
buildInterpolatedPomFile method also would use, optionally if you wish, the
project's own properties and not just the supplied
parameter values.
Simple use case:
Using the [maven-component-it-plugin to inject the project's local
repository|https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-component-it-plugin]
path into the project's main properties would then allow us to use this value
to build a simple 'local repository as a main repository' into the
IT plugin POMS which would allow us to greatly speed up testing.
The [assembly
plugin|https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/pom.xml]
currently jumps through the hoops of filtering and installing a special IT
parent pom project to interpolate this 'local repo property value' into a POM
and then the IT poms use this parent and thus have access to the special
repository of the form:
main.local.as.remote
file://${local.repo.path}
main.local.as.remote
file://${local.repo.path}
If the invoker was willing to use the main project's Properties as well as the
explicitly defined in interpolation we could remove
the need for this filtering and installing and simply get the job done from in
one simple call.
--
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: (MNG-3344) Provide new POM element to configure site directory (e.g. "src/site")
[
http://jira.codehaus.org/browse/MNG-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118824
]
John Allen commented on MNG-3344:
-
I think there are a few reporting plugins that have had to rely upon using the
default location hardcoded due to the fact that it was not programmably
retrievable from the project model or the site plugin configuration. will have
to fix those up incrementally i guess.
> Provide new POM element to configure site directory (e.g. "src/site")
> -
>
> Key: MNG-3344
> URL: http://jira.codehaus.org/browse/MNG-3344
> Project: Maven 2
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
> Fix For: 2.1-alpha-1
>
>
> As requested in MSITE-91 and its various duplicates, the input location for
> the site generation should be configurable. Currently, this is realized by a
> configuration parameter (siteDirectory) for the maven-site-plugin itself but
> I argue that this is not sufficient/robust for all cases. The problem is that
> the plugin cannot access its configuration in ancestor POMs and hence can
> only guess.
> For example, take the following multi-module scenario:
> project-parent/
> doc/
> site.xml
> project-module/
> src/
> site/
> site.xml
> Let us ignore the fact that such is layout is unusual, weird, bad-practice or
> whatever you would like to call it. The point is, it should be possible. The
> important aspect of the example is that both POMs will need to use a
> different configuration of the maven-site-plugin to find the site descriptor
> (and related files). The parent POM will have siteDirectory=doc while the
> module POM will have siteDirectory=src/site.
> Now consider the plugin's steps when building the site for project-module.
> From the plugin configuration in "project-module/pom.xml", it knows to search
> the site descriptor for the sub project in "src/site". To apply inheritance,
> the plugin then needs to locate the site descriptor of the parent project.
> Ups. The plugin cannot access the corresponding plugin configuration in
> "project-parent/pom.xml". So it can only assume that the parent uses the same
> directory layout for the site as the current sub module.
> Having a dedicated POM element for the site files, e.g.
> ${project.reporting.siteDirectory}, would allow the maven-site-plugin to
> properly determine the location of the site descriptor of any ancestor
> project. The super POM can default this element to "src/site" to get the
> usual behavior.
--
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: (MNG-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118450
]
skaze edited comment on MNG-3244 at 1/5/08 7:55 AM:
-
After playing with some patch some more i came across another problem beyond
the one mentioned above. You need to ensure that the trailing slash is
propagated to the child projects URLs (distroManagement.site.url and
project.url) otherwise the logic based upon the presence of the trailing slash
stop working. i.e. if you call appendPaths you must ensure that the resulting
path ends with a '/'.
was (Author: skaze):
After playing with some patch some more i came across another problem
beyond the one mentioned above. You need to ensure that a trailing slash is
present in the child assembled projects otherwise the logic based upon the
presence of the trailing slash stop working. i.e. if you call appendPaths you
must ensure that the resulting path ends with a '/'.
> inherited site url not properly handling parameters
> ---
>
> Key: MNG-3244
> URL: http://jira.codehaus.org/browse/MNG-3244
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: Jacob Robertson
>Assignee: Brian Fox
> Fix For: 2.0.9
>
> Attachments: fix-inherited-site-url.patch, guide-site.patch
>
>
> Here is the test case to reroduce this problem. Take the following two
> pom.xml files
>
>
> org.bar
> foo
> foo
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
>
> foo-site
> file://C:/Documents and
> Settings/foo/.m2/site/${project.artifactId}
>
>
>
>
>
> org.bar
> baz
> baz
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
> foo
> org.bar
> 1.0-SNAPSHOT
>
>
> And run the site-deploy goal on each. What you get under the site directory
> is this
> - site
> /- foo
> ---/site docs
> /- baz
> ---/- baz (extra directory)
> --- ---/site docs
> This is the simplest test case. In the case where I have a "grandparent"
> pom, the site directory uses the grandparent/parent as the path to the site,
> and doesn't use the actual artifactId of the artifact I'm creating the site
> for.
--
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: (MNG-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118450
]
John Allen commented on MNG-3244:
-
After playing with some patch some more i came across another problem beyond
the one mentioned above. You need to ensure that a trailing slash is present in
the child assembled projects otherwise the logic based upon the presence of the
trailing slash stop working. i.e. if you call appendPaths you must ensure that
the resulting path ends with a '/'.
> inherited site url not properly handling parameters
> ---
>
> Key: MNG-3244
> URL: http://jira.codehaus.org/browse/MNG-3244
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: Jacob Robertson
>Assignee: Brian Fox
> Fix For: 2.0.9
>
> Attachments: fix-inherited-site-url.patch, guide-site.patch
>
>
> Here is the test case to reroduce this problem. Take the following two
> pom.xml files
>
>
> org.bar
> foo
> foo
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
>
> foo-site
> file://C:/Documents and
> Settings/foo/.m2/site/${project.artifactId}
>
>
>
>
>
> org.bar
> baz
> baz
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
> foo
> org.bar
> 1.0-SNAPSHOT
>
>
> And run the site-deploy goal on each. What you get under the site directory
> is this
> - site
> /- foo
> ---/site docs
> /- baz
> ---/- baz (extra directory)
> --- ---/site docs
> This is the simplest test case. In the case where I have a "grandparent"
> pom, the site directory uses the grandparent/parent as the path to the site,
> and doesn't use the actual artifactId of the artifact I'm creating the site
> for.
--
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: (MNG-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118289
]
John Allen commented on MNG-3244:
-
remember that the site distro URL and the project URL are related. If you add
the documented but missing feature of being '/' aware for one of them (i.e. as
you have with this patch and its handling of site distro url) you will need to
add the same feature to the project url assembly.
We have had to declare explicit project.url and distroManagement.site.url
elements in EVERY pom of our multi-module proejcts because we also use real
identifying information in these URLS, namely the
${project.groupId}/${project.artifactId}/${project.version}
> inherited site url not properly handling parameters
> ---
>
> Key: MNG-3244
> URL: http://jira.codehaus.org/browse/MNG-3244
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: Jacob Robertson
>Assignee: Brian Fox
> Fix For: 2.0.9
>
> Attachments: fix-inherited-site-url.patch, guide-site.patch
>
>
> Here is the test case to reroduce this problem. Take the following two
> pom.xml files
>
>
> org.bar
> foo
> foo
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
>
> foo-site
> file://C:/Documents and
> Settings/foo/.m2/site/${project.artifactId}
>
>
>
>
>
> org.bar
> baz
> baz
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
> foo
> org.bar
> 1.0-SNAPSHOT
>
>
> And run the site-deploy goal on each. What you get under the site directory
> is this
> - site
> /- foo
> ---/site docs
> /- baz
> ---/- baz (extra directory)
> --- ---/site docs
> This is the simplest test case. In the case where I have a "grandparent"
> pom, the site directory uses the grandparent/parent as the path to the site,
> and doesn't use the actual artifactId of the artifact I'm creating the site
> for.
--
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: (MINVOKER-14) release maven-invoker
[ http://jira.codehaus.org/browse/MINVOKER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116431 ] John Allen commented on MINVOKER-14: would allow us to drop local corporate version +1 > release maven-invoker > - > > Key: MINVOKER-14 > URL: http://jira.codehaus.org/browse/MINVOKER-14 > Project: Maven 2.x Invoker Plugin > Issue Type: Task >Affects Versions: 1.1 >Reporter: Olivier Lamy >Assignee: John Casey >Priority: Blocker > Fix For: 1.1 > > > a new release of maven-invoker is needed to release maven-invoker-plugin 1.1 -- 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: (MRELEASE-230) release:prepare cannot update the version of a module in a multi-module build if you have both normal artifact and attached artifact in dependencies
[ http://jira.codehaus.org/browse/MRELEASE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113386 ] John Allen commented on MRELEASE-230: - did you develop a patch for this? > release:prepare cannot update the version of a module in a multi-module build > if you have both normal artifact and attached artifact in dependencies > > > Key: MRELEASE-230 > URL: http://jira.codehaus.org/browse/MRELEASE-230 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Chris Wewerka > Attachments: release-test.zip > > > Following situation: > you have a multimodule build with 2 modules A,B, and B has two dependencies > to A, one for the "normal" jar artifact and one for an attached artifact > (e.g. the test-jar of A). > The release will fail with: > ... > [INFO] Transforming 'O2 Release test Base Module'... > [INFO] Checking out file: > E:\prj\o2\branches\main_latest\sd_pa\tools\release-test\pom.xml > [INFO] Transforming 'release-test-module-one'... > [INFO] Checking out file: > E:\prj\o2\branches\main_latest\sd_pa\tools\release-test\release-test-module-one\pom.xml > [INFO] Transforming 'release-test-module-two'... > [INFO] Updating release-test-module-one to 5.0.2 > [INFO] Updating release-test-module-one to 5.0.2 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] The version could not be updated: 5.0.2 > [INFO] > > [INFO] For more information, run Maven with the -e switch -- 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] Created: (MNG-3249) Profile resident POM element overrides do not effect inherited projects if the children have their own explicitly defined elements.
Profile resident POM element overrides do not effect inherited projects if the children have their own explicitly defined elements. --- Key: MNG-3249 URL: http://jira.codehaus.org/browse/MNG-3249 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.7 Reporter: John Allen If i declare a profile in a base pom that overrides settings in the POM, those settings are only overridden in the base POM and not in the inherited children in a reactor build if the children also explicitly define their own values for those overridden settings. I almost didn't create this as you could argue that that is how children maintain control but I think the profile evaluation should be applied to each level of the hierarchy, as the inheritance model is built up, i.e. I expect the children to inherit the profile too, not just the application of that profile to it's ancestors state and thus that profile should applied to the child's model, after the rest of the child's inherited state has been established, and thus it should still override the child's settings. -- 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: (MPMD-55) The Xml pmd file isn't encode to UTF8 charset counter the charset declaration in the file header
[ http://jira.codehaus.org/browse/MPMD-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110084 ] John Allen commented on MPMD-55: Just encountered this ourselves, what's the fix? > The Xml pmd file isn't encode to UTF8 charset counter the charset declaration > in the file header > > > Key: MPMD-55 > URL: http://jira.codehaus.org/browse/MPMD-55 > Project: Maven 2.x PMD Plugin > Issue Type: Bug >Reporter: pkernevez > Attachments: PMD-UTF8-Encode.patch > > > The Xml file (target/pmd.xml) declare an UTF-8 encoding: " encoding="UTF-8"?>" but use the FileWriter API that encode caracter with the > default charset of the platform. > Non ACSII caracter couldn't be read and xml file couldn't be parsed with Xml > Parser due to this error. > The patch contains the testcode and the correction -- 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: (MPMD-55) The Xml pmd file isn't encode to UTF8 charset counter the charset declaration in the file header
[ http://jira.codehaus.org/browse/MPMD-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110084 ] John Allen edited comment on MPMD-55 at 10/16/07 12:53 PM: --- Just encountered this ourselves, will try patch locally was: Just encountered this ourselves, what's the fix? > The Xml pmd file isn't encode to UTF8 charset counter the charset declaration > in the file header > > > Key: MPMD-55 > URL: http://jira.codehaus.org/browse/MPMD-55 > Project: Maven 2.x PMD Plugin > Issue Type: Bug >Reporter: pkernevez > Attachments: PMD-UTF8-Encode.patch > > > The Xml file (target/pmd.xml) declare an UTF-8 encoding: " encoding="UTF-8"?>" but use the FileWriter API that encode caracter with the > default charset of the platform. > Non ACSII caracter couldn't be read and xml file couldn't be parsed with Xml > Parser due to this error. > The patch contains the testcode and the correction -- 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] Created: (MNG-3192) Properties not effective in inherited elements in child projects
Properties not effective in inherited
elements in child projects
Key: MNG-3192
URL: http://jira.codehaus.org/browse/MNG-3192
Project: Maven 2
Issue Type: Bug
Reporter: John Allen
Setting to either true or false in a
parent project section will control whether or not that report is
inherited by a child. Changing the value of to be an expression,
such as ${inheritThisReport} and setting that property in the parent POM to
either true or false, prevents the report from appearing in all children
regardless or its value.
--
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: (MSITE-209) populateModulesMenu() logic results in invalid modules list if projects share artifactIds
[
http://jira.codehaus.org/browse/MSITE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106281
]
John Allen commented on MSITE-209:
--
Crazy busy at the moment but yes of course (will take some time though sorry).
The logic above is fairly self-evident though. Namely increase the name
matching resolution to include an artefacts groupId as well as artifactId.
> populateModulesMenu() logic results in invalid modules list if projects share
> artifactIds
> -
>
> Key: MSITE-209
> URL: http://jira.codehaus.org/browse/MSITE-209
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0-beta-6
>Reporter: John Allen
>Priority: Critical
> Attachments: site-patch.diff, site-patch.diff
>
>
> populateModulesMenu() logic should compare groupIds as well as artifactIds.
> Failure to do so can result in invalid modules list being generated when the
> reactorProject.getParent().getArtifectId() is the same as the current project
> but is not of the same group. Logic should be (dont have the code available
> as its on my laptop), oh go on then Ill HTTP the source
> private void populateModulesMenuItemsFromReactorProjects( Menu menu )
> {
> [SNIP]
> if ( reactorProject != null && reactorProject.getParent() !=
> null &&
> project.getArtifactId().equals(
> reactorProject.getParent().getArtifactId() ) )
> {
> String reactorUrl = reactorProject.getUrl();
> String name = reactorProject.getName();
> appendMenuItem( menu, name, reactorUrl,
> reactorProject.getArtifactId() );
> }
> }
> }
> }
> Comparison should also check that the groupId of the reactorProject's parent
> matches our groupId.
> Clear?.. Sorry, the patch on my laptop too...
--
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] Created: (SUREFIRE-348) Proivde a surefire aggregate option for report-only mojo
Proivde a surefire aggregate option for report-only mojo Key: SUREFIRE-348 URL: http://jira.codehaus.org/browse/SUREFIRE-348 Project: Maven Surefire Issue Type: New Feature Components: report plugin Affects Versions: 2.3 Reporter: John Allen I have recently modified many plugins to provide aggregate features that aggregate their respective reports for contained sub-n-modules (inc. sub-sub etc) up the *module* hierarchy (ie not inheritance hierarchy that may be unrelated to the reactor and module structure) and would like to see this for surefire. This enables use view reports for various levels of sub-systems resulting in top level reports that cover an entire solution. I would like to request this feature for the report-only mojo (god knows how you;d do it for the forking surefire:report one) My recommendation is either to separate aggregate into a separate mojo that pulls the surefire result xml files up the tree, merging them as it goes and then have report-only simply knock out a report for the, now aggregated report files it finds when its run as part of site. With is the site generation model one binds these kinds of site preprocessing mojos, that themselves tend to be able to @aggregatorrs (thus also getting round the bug where reporting mojos cant be aggregators) to the pre-site phase. This is our preferred technique to site building where one treats analysis a part of the normal build lifecycle (for how else would one be able to run checkers that read the analysis and fail the build if thresholds are breached?) and reporting do nothing but report on the data that has been produced by the normal build and analysis phases (ie no evil forked lifecycles). The alternative is to pull the data up to the scope that the report-only mojo is running at from the sub-n-modules beneath it before it then reports on it. The mojo obviously gets run for each level of the module hierarchy as the reactor is processed. This can be optimised to do all the work at the top most module if one wants - i.e. build the merged aggregated data files for all the sub-modules on those modules behalf, as it builds its top-most aggregated data file (ie it populates sub-module target/surefire directories with their merged report xml for them as it needs this info for its report). Note I do not know (or like) why the assumptions present in Javadoc and JXR that if one want to aggregate one only wants to aggregate to the top most project.. -- 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-245) parent filesystem site.xml is never be found
[
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104922
]
John Allen edited comment on MSITE-245 at 8/15/07 11:10 AM:
I'm not sure I exactly follow you John, I've had a look at the patch and the
opening line in it is to remove the existing relativePath logic altogether:
{code}
-String relativePath = getRelativePath(
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}
When i think about this method I see a very simple purpose, namely to try and
find a site+locale+xml file for the passed in project, and if a locale specific
one can not be found, to assume that a default site.xml will exist. Clients of
the method obviously know that the returned File object may or may not exist so
it's not necessary for this methods to check for that.
Ideally we would pass in the MavenProject object we're interrogating here
rather than it's basedir as this would provide more opportunities in the future
to try and find the real site directory for the operand project, however as
that is not a model parameter and is instead a configuration parameter of the
site plugin itself, we would need a way of looking at the configuration
settings of the site plugin for the passed in project and I don't think we have
a ppropriate way of doing this at the moment.
This method, as you know, is used for two things. One, to get this project's
site.xml (prefering a locale based one) and secondly to try and find other
project's site.xml files as the client code tries to peek up the project
inheritance hierarchy. Neither of these uses cases seem to warrant a relative
path approach, after all there is no need to use a relative path when we have
explicit paths to work with and, once we find the file, (or not as the case
maybe) we instantiate a File object from it, so we loose any interest in
whether the File object's location (i.e. the site.xml filename and path) was
found via a relative path approach or not.
The method does have one concession to supporting a site.xml file that is being
stored in a 'non default' location but that only comes when looking for 'this'
project's site.xml file as we have access to this project's site plugin
configuration.
We could take a stance that when trying to find any project's site xml file we
assume it will use the same site directory location that this project is using:
{code}
protected File getSiteDescriptorFile( File basedir, Locale locale )
{
String sitePath;
if ( basedir.equals( project.getBasedir() ))
{
// it's this project's basedir so use our siteDirectory
sitePath = siteDirectory.getAbsolutePath();
}
else
{
// it's not this project's basedir so it must be one of our parent's
// so lets assume they store their site.xml in the same location
relative
// to their basedir as we do
String ourRelativeSiteDirectory =
siteDirectory.getAbsolutePath().substring(
0, project.getBasedir().getAbsolutePath().length() );
sitePath = basedir.getAbsolutePath() + "/" +
ourRelativeSiteDirectory;
}
File siteDescriptor = new File( sitePath, "site_" +
locale.getLanguage() + ".xml" );
if ( !siteDescriptor.exists() )
{
siteDescriptor = new File( sitePath, "site.xml" );
}
return siteDescriptor;
{code}
Thus if this project stores its site files in ${basedir}/src/foo then we will
try and find all site.xml files in the directory src/foo. In fact we could go a
step further and try that first and if we fail then fall back to trying the
standard default location of src/site.
Don't know if I've helped here:)
ps. The code block above was written in JIRA and has not been tested, its just
for illustration
was:
I'm not sure I exactly follow you John, I've had a look at the patch and the
opening line in it is to remove the existing relativePath logic altogether:
{code}
-String relativePath = getRelativePath(
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}
When i think about this method I see a very simple purpose, namely to try and
find a site+locale+xml file for the passed in project, and if a locale specific
one can not be found, to assume that a default site.xml will exist. Clients of
the method obviously know that the returned File object may or may not exist so
it's not necessary for this methods to check for that.
Ideally we would pass in the MavenProject object we're interrogating here
rather than it's basedir as this would provide more opportunities in the future
to try and find the real site directory for the operand project, however as
that is not a model parameter and is instead a configuration parameter of the
site p
[jira] Issue Comment Edited: (MSITE-245) parent filesystem site.xml is never be found
[
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104922
]
John Allen edited comment on MSITE-245 at 8/15/07 10:49 AM:
I'm not sure I exactly follow you John, I've had a look at the patch and the
opening line in it is to remove the existing relativePath logic altogether:
{code}
-String relativePath = getRelativePath(
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}
When i think about this method I see a very simple purpose, namely to try and
find a site+locale+xml file for the passed in project, and if a locale specific
one can not be found, to assume that a default site.xml will exist. Clients of
the method obviously know that the returned File object may or may not exist so
it's not necessary for this methods to check for that.
Ideally we would pass in the MavenProject object we're interrogating here
rather than it's basedir as this would provide more opportunities in the future
to try and find the real site directory for the operand project, however as
that is not a model parameter and is instead a configuration parameter of the
site plugin itself, we would need a way of looking at the configuration
settings of the site plugin for the passed in project and I don't think we have
a ppropriate way of doing this at the moment.
This method, as you know, is used for two things. One, to get this project's
site.xml (prefering a locale based one) and secondly to try and find other
project's site.xml files as the client code tries to peek up the project
inheritance hierarchy. Neither of these uses cases seem to warrant a relative
path approach, after all there is no need to use a relative path when we have
explicit paths to work with and, once we find the file, (or not as the case
maybe) we instantiate a File object from it, so we loose any interest in
whether the File object's location (i.e. the site.xml filename and path) was
found via a relative path approach or not.
The method does have one concession to supporting a site.xml file that is being
stored in a 'non default' location but that only comes when looking for 'this'
project's site.xml file as we have access to this project's site plugin
configuration.
We could take a stance that when trying to find any project's site xml file we
assume it will use the same site directory location that this project is using:
{code}
protected File getSiteDescriptorFile( File basedir, Locale locale )
{
String sitePath;
if ( basedir.equals( project.getBasedir() ))
{
// it's this project's basedir so use our siteDirectory
sitePath = siteDirectory.getAbsolutePath();
}
else
{
// it's not this project's basedir so it must be one of our parent's
// so lets assume they store their site.xml in the same location
relative
// to their basedir as we do
String siteRelativeDirectory = getRelativePath(
siteDirectory.getAbsolutePath(), project.getBasedir().getAbsolutePath() );
sitePath = basedir.getAbsolutePath() + "/" + siteRelativeDirectory;
}
File siteDescriptor = new File( sitePath, "site_" +
locale.getLanguage() + ".xml" );
if ( !siteDescriptor.exists() )
{
siteDescriptor = new File( sitePath, "site.xml" );
}
return siteDescriptor;
{code}
Thus if this project stores its site files in ${basedir}/src/foo then we will
try and find all site.xml files in the directory src/foo. In fact we could go a
step further and try that first and if we fail then fall back to trying the
standard default location of src/site.
Don't know if I've helped here:)
ps. The code block above was written in JIRA and has not been tested, its just
for illustration
was:
I'm not sure I exactly follow you John, I've had a look at the patch and the
opening line in it is to remove the existing relativePath logic altogether:
{code}
-String relativePath = getRelativePath(
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}
When i think about this method I see a very simple purpose, namely to try and
find a site+locale+xml file for the passed in project, and if a locale specific
one can not be found, to assume that a default site.xml will exist. Clients of
the method obviously know that the returned File object may or may not exist so
it's not necessary for this methods to check for that.
Ideally we would pass in the MavenProject object we're interrogating here
rather than it's basedir as this would provide more opportunities in the future
to try and find the real site directory for the operand project, however as
that is not a model parameter and is instead a configuration parameter of the
site plugin itself, we would need a way of looking at t
[jira] Commented: (MSITE-245) parent filesystem site.xml is never be found
[
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104922
]
John Allen commented on MSITE-245:
--
I'm not sure I exactly follow you John, I've had a look at the patch and the
opening line in it is to remove the existing relativePath logic altogether:
{code}
-String relativePath = getRelativePath(
siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
{code}
When i think about this method I see a very simple purpose, namely to try and
find a site+locale+xml file for the passed in project, and if a locale specific
one can not be found, to assume that a default site.xml will exist. Clients of
the method obviously know that the returned File object may or may not exist so
it's not necessary for this methods to check for that.
Ideally we would pass in the MavenProject object we're interrogating here
rather than it's basedir as this would provide more opportunities in the future
to try and find the real site directory for the operand project, however as
that is not a model parameter and is instead a configuration parameter of the
site plugin itself, we would need a way of looking at the configuration
settings of the site plugin for the passed in project and I don't think we have
a ppropriate way of doing this at the moment.
This method, as you know, is used for two things. One, to get this project's
site.xml (prefering a locale based one) and secondly to try and find other
project's site.xml files as the client code tries to peek up the project
inheritance hierarchy. Neither of these uses cases seem to warrant a relative
path approach, after all there is no need to use a relative path when we have
explicit paths to work with and, once we find the file, (or not as the case
maybe) we instantiate a File object from it, so we loose any interest in
whether the File object's location (i.e. the site.xml filename and path) was
found via a relative path approach or not.
The method does have one concession to supporting a site.xml file that is being
stored in a 'non default' location but that only comes when looking for 'this'
project's site.xml file as we have access to this project's site plugin
configuration.
We could take a stance that when trying to find any project's site xml file we
assume it will use the same site directory location that this project is using:
{code}
protected File getSiteDescriptorFile( File basedir, Locale locale )
{
String sitePath;
if ( basedir.equals( project.getBasedir() ))
{
// it's this project's basedir so use our siteDirectory
sitePath = siteDirectory.getAbsolutePath();
}
else
{
// it's not this project's basedir so it must be one of our parent's
// so lets assume they store their site.xml in the same location
relative
// to their basedir as we do
String siteRelativeDirectory = getRelativePath(
siteDirectory.getAbsolutePath(), project.getBasedir().getAbsolutePath() );
sitePath = basedir.getAbsolutePath() + "/" + siteRelativeDirectory;
}
File siteDescriptor = new File( sitePath, "site_" +
locale.getLanguage() + ".xml" );
if ( !siteDescriptor.exists() )
{
siteDescriptor = new File( sitePath, "site.xml" );
}
return siteDescriptor;
{code}
Thus if this project stores its site files in ${basedir}/src/foo then we will
try and find all site.xml files in the directory src/foo. In fact we could go a
step further and try that first and if we fail then fall back to trying the
standard default location of src/site.
Don;t know if I've helped here:)
> parent filesystem site.xml is never be found
>
>
> Key: MSITE-245
> URL: http://jira.codehaus.org/browse/MSITE-245
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: 2.0.7
>Reporter: John Allen
>Assignee: John Casey
>Priority: Blocker
> Attachments: site-patch.txt
>
>
> The current approach used by the getSiteDescriptorFile(File, Locale) is wrong
> as the basedir passed in to it is not just the project's own basedir, it's
> potentially a parent project's basedir and thus the previous code makes no
> sense as we would need to add on the parent's site.xml site directory and
> then try and find the relative path to it and as there's no way (that I know
> of) of a) finding that out from the parent project's object model (even if we
> passed it in) and b) the current code does not append anything to the passed
> in basedir so is always looking for a site.xml in the parents root directory.
> What's more the use of a relative path here is pointless too as we simp
[jira] Commented: (MNG-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104030
]
John Allen commented on MNG-2290:
-
This is an issue that we've been living with for ages and continues to result
in hassle and bugs (today: MNG-3134).
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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: (MNG-2209) Calculation of module URLs does not match deployment
[ http://jira.codehaus.org/browse/MNG-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104029 ] John Allen edited comment on MNG-2209 at 8/5/07 11:27 AM: -- MNG-3134 fixes this issue was: MNG3133 fixes this issue > Calculation of module URLs does not match deployment > > > Key: MNG-2209 > URL: http://jira.codehaus.org/browse/MNG-2209 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, POM >Affects Versions: 2.0.4 > Environment: Site plugin built from SVN revision 391930 >Reporter: Bob Allison >Priority: Blocker > Fix For: 2.1.x > > Attachments: sitetest.tar > > > In a project where the parent project is a peer directory with its children > (e.g., top/parent/pom.xml, top/child/pom.xml, ...) the site is deployed > correctly (site/parent, site/parent/child, ...) but the links in the left > menu are not generated correctly (site/parent, site/child, ...) > Attached tar file contains three projects: parent, child1, and child2. > Unpack these into a directory, change to the parent directory, and do a "mvn > site". The generated links for the first child project is > "http://child1/index.html";. -- 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] Created: (MNG-3134) DefaultModelInheritence::assembleDistributionInheritence should be childPathAdjustment aware
DefaultModelInheritence::assembleDistributionInheritence should be childPathAdjustment aware Key: MNG-3134 URL: http://jira.codehaus.org/browse/MNG-3134 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.7 Reporter: John Allen Priority: Critical Attachments: patch.txt In the same way that the URL, and SCM inheritance assembly is 'childPathAdjustment' aware, so should the site distribution URL. The childPathAdjustment value takes into account a child's relative location to its parent, such that 'children' (modules) that are declared via ../../foo/bar end up with paths that are accurate for their location within the external namespaces (ie the SCM namespace or the URL namespace). However this is not being done for the site distribution URL which is obviously a bug as the project URL, which remember is childPathAdjustment aware, has a direct coupling to the distroManagement.site.URL. Patch against maven-project 2.0.7 attached. -- 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] Created: (MNG-3133) DefaultModelInheritence::appendPath assumes it is operating on interpolated/literal paths
DefaultModelInheritence::appendPath assumes it is operating on
interpolated/literal paths
-
Key: MNG-3133
URL: http://jira.codehaus.org/browse/MNG-3133
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.7
Reporter: John Allen
Priority: Critical
Used by all the assembleXXXInheritance methods within assembleModelInheritance,
the appendPath method assumes that its dealing with literal paths which is not
a documented restriction. Thus having ${expressions} in any of the paths being
operated on (e.g. project URL, distroManagement site, SCM, etc etc), the
results will not be valid.
This whole area of Maven's core requires a specification so it can be coded too
and maintained.
--
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: (MJAVADOC-140) test-javadoc run in aggregate mode does not pass correct classpath to javadoc tool
[
http://jira.codehaus.org/browse/MJAVADOC-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103999
]
John Allen commented on MJAVADOC-140:
-
except I don't think getExecutionProject can be relied upon to always return a
valid reference, as discovered in ticket MJAVADOC-139
> test-javadoc run in aggregate mode does not pass correct classpath to javadoc
> tool
> --
>
> Key: MJAVADOC-140
> URL: http://jira.codehaus.org/browse/MJAVADOC-140
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: John Allen
>Priority: Blocker
>
> compare - local build of test-javadoc for a project:
> {code}
> -classpath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
> D:/PROFILES/allenj4/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar'
> -protected
> -sourcepath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
> -author
> -charset
> 'ISO-8859-1'
> -d
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/target/site/testapidocs'
> -doctitle
> 'Calculator Engine 1.1-SNAPSHOT Test API'
> -linkoffline
> 'http://java.sun.com/j2se/1.4.2/docs/api' null
> -use
> -version
> -windowtitle
> 'Calculator Engine 1.1-SNAPSHOT Test API'
> {code}
> with the one produced at the root project. It obviously contains many more
> classpath details but critically you'll see junit JAR
> {code}
> -classpath
> 'D:/APT/projects/apt-examples/calculator/calculator-root/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-root/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-skin/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-skin/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-ejb/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-ejb/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-servlets/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-servlets/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-webapp/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-webapp/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-ear/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-ear/target/test-classes;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-servlets/1.1-SNAPSHOT/calculator-servlets-1.1-SNAPSHOT.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT-client.jar;
> D:/PROFILES/allenj4/.m2/repository/javax/j2ee/j2ee/1.4/j2ee-1.4.jar;
> D:/PROFILES/allenj4/.m2/repository/tomcat/jasper-runtime/5.5.12/jasper-runtime-5.5.12.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-engine/1.1-SNAPSHOT/calculator-engine-1.1-SNAPSHOT.jar'
> -protected
> -sourcepath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
> -author
> -charset
> 'ISO-8859-1'
> -d
> 'D:/APT/projects/apt-examples/calculator/calculator-root/target/site/testapidocs'
> -doctitle
> 'Calculator 1.1-SNAPSHOT Test API'
> -linkoffline
> 'http://java.sun.com/j2se/1.4.2/docs/api' null
> -use
> -version
> -windowtitle
> 'Calculator 1.1-SNAPSHOT Test API'
> {code}
> Which of course gives us:
> {code}
> [INFO] Javadoc Warnings
> [WARNING]
> D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:6:
> package junit.framework does not exist
> [WARNING] import junit.framework.TestCase;
> [WARNING] ^
> [WARNING]
> D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:13:
> cannot find symbol
> [WARNING] symbol: class TestCase
> [WARNING] extends TestCase
> [WARNING] ^
> {code}
--
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: (MJAVADOC-140) test-javadoc run in aggregate mode does not pass correct classpath to javadoc tool
[
http://jira.codehaus.org/browse/MJAVADOC-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103594
]
John Allen commented on MJAVADOC-140:
-
I only saw maven-javadoc-plugin\src\it\MJAVADOC-110 under IT, do the ITs reside
somewhere else too?
> test-javadoc run in aggregate mode does not pass correct classpath to javadoc
> tool
> --
>
> Key: MJAVADOC-140
> URL: http://jira.codehaus.org/browse/MJAVADOC-140
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: John Allen
>Priority: Blocker
>
> compare - local build of test-javadoc for a project:
> {code}
> -classpath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
> D:/PROFILES/allenj4/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar'
> -protected
> -sourcepath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
> -author
> -charset
> 'ISO-8859-1'
> -d
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/target/site/testapidocs'
> -doctitle
> 'Calculator Engine 1.1-SNAPSHOT Test API'
> -linkoffline
> 'http://java.sun.com/j2se/1.4.2/docs/api' null
> -use
> -version
> -windowtitle
> 'Calculator Engine 1.1-SNAPSHOT Test API'
> {code}
> with the one produced at the root project. It obviously contains many more
> classpath details but critically you'll see junit JAR
> {code}
> -classpath
> 'D:/APT/projects/apt-examples/calculator/calculator-root/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-root/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-skin/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-skin/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-ejb/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-ejb/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-servlets/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-servlets/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-webapp/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-webapp/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-ear/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-ear/target/test-classes;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-servlets/1.1-SNAPSHOT/calculator-servlets-1.1-SNAPSHOT.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT-client.jar;
> D:/PROFILES/allenj4/.m2/repository/javax/j2ee/j2ee/1.4/j2ee-1.4.jar;
> D:/PROFILES/allenj4/.m2/repository/tomcat/jasper-runtime/5.5.12/jasper-runtime-5.5.12.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-engine/1.1-SNAPSHOT/calculator-engine-1.1-SNAPSHOT.jar'
> -protected
> -sourcepath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
> -author
> -charset
> 'ISO-8859-1'
> -d
> 'D:/APT/projects/apt-examples/calculator/calculator-root/target/site/testapidocs'
> -doctitle
> 'Calculator 1.1-SNAPSHOT Test API'
> -linkoffline
> 'http://java.sun.com/j2se/1.4.2/docs/api' null
> -use
> -version
> -windowtitle
> 'Calculator 1.1-SNAPSHOT Test API'
> {code}
> Which of course gives us:
> {code}
> [INFO] Javadoc Warnings
> [WARNING]
> D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:6:
> package junit.framework does not exist
> [WARNING] import junit.framework.TestCase;
> [WARNING] ^
> [WARNING]
> D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:13:
> cannot find symbol
> [WARNING] symbol: class TestCase
> [WARNING] extends TestCase
> [WARNING] ^
> {code}
--
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: (MJAVADOC-140) test-javadoc run in aggregate mode does not pass correct classpath to javadoc tool
[
http://jira.codehaus.org/browse/MJAVADOC-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103570
]
John Allen commented on MJAVADOC-140:
-
I will try to when I can find some time.
Btw, I have come across quite a few bugs in the recently released plugins
(javadoc, jxr, site, clover) that do not show up with the stub mojo testing
approach but do when run against real project structures. I will create a test
multimodule project environment and attach it when I can.
> test-javadoc run in aggregate mode does not pass correct classpath to javadoc
> tool
> --
>
> Key: MJAVADOC-140
> URL: http://jira.codehaus.org/browse/MJAVADOC-140
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: John Allen
>Priority: Blocker
>
> compare - local build of test-javadoc for a project:
> {code}
> -classpath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
> D:/PROFILES/allenj4/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar'
> -protected
> -sourcepath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
> -author
> -charset
> 'ISO-8859-1'
> -d
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/target/site/testapidocs'
> -doctitle
> 'Calculator Engine 1.1-SNAPSHOT Test API'
> -linkoffline
> 'http://java.sun.com/j2se/1.4.2/docs/api' null
> -use
> -version
> -windowtitle
> 'Calculator Engine 1.1-SNAPSHOT Test API'
> {code}
> with the one produced at the root project. It obviously contains many more
> classpath details but critically you'll see junit JAR
> {code}
> -classpath
> 'D:/APT/projects/apt-examples/calculator/calculator-root/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-root/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-skin/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-skin/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-ejb/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-ejb/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-servlets/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-servlets/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-webapp/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-webapp/target/test-classes;
> D:/APT/projects/apt-examples/calculator/calculator-ear/target/classes;
> D:/APT/projects/apt-examples/calculator/calculator-ear/target/test-classes;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-servlets/1.1-SNAPSHOT/calculator-servlets-1.1-SNAPSHOT.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT-client.jar;
> D:/PROFILES/allenj4/.m2/repository/javax/j2ee/j2ee/1.4/j2ee-1.4.jar;
> D:/PROFILES/allenj4/.m2/repository/tomcat/jasper-runtime/5.5.12/jasper-runtime-5.5.12.jar;
> D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-engine/1.1-SNAPSHOT/calculator-engine-1.1-SNAPSHOT.jar'
> -protected
> -sourcepath
> 'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
> -author
> -charset
> 'ISO-8859-1'
> -d
> 'D:/APT/projects/apt-examples/calculator/calculator-root/target/site/testapidocs'
> -doctitle
> 'Calculator 1.1-SNAPSHOT Test API'
> -linkoffline
> 'http://java.sun.com/j2se/1.4.2/docs/api' null
> -use
> -version
> -windowtitle
> 'Calculator 1.1-SNAPSHOT Test API'
> {code}
> Which of course gives us:
> {code}
> [INFO] Javadoc Warnings
> [WARNING]
> D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:6:
> package junit.framework does not exist
> [WARNING] import junit.framework.TestCase;
> [WARNING] ^
> [WARNING]
> D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:13:
> cannot find symbol
> [WARNING] symbol: class TestCase
> [WARNING] extends TestCase
> [WARNING] ^
> {code}
--
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] Created: (MJAVADOC-140) test-javadoc run in aggregate mode does not pass correct classpath to javadoc tool
test-javadoc run in aggregate mode does not pass correct classpath to javadoc
tool
--
Key: MJAVADOC-140
URL: http://jira.codehaus.org/browse/MJAVADOC-140
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: John Allen
Priority: Blocker
compare - local build of test-javadoc for a project:
{code}
-classpath
'D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
D:/PROFILES/allenj4/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar'
-protected
-sourcepath
'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
-author
-charset
'ISO-8859-1'
-d
'D:/APT/projects/apt-examples/calculator/calculator-engine/target/site/testapidocs'
-doctitle
'Calculator Engine 1.1-SNAPSHOT Test API'
-linkoffline
'http://java.sun.com/j2se/1.4.2/docs/api' null
-use
-version
-windowtitle
'Calculator Engine 1.1-SNAPSHOT Test API'
{code}
with the one produced at the root project. It obviously contains many more
classpath details but critically you'll see junit JAR
{code}
-classpath
'D:/APT/projects/apt-examples/calculator/calculator-root/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-root/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-skin/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-skin/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-engine/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-engine/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-ejb/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-ejb/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-servlets/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-servlets/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-webapp/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-webapp/target/test-classes;
D:/APT/projects/apt-examples/calculator/calculator-ear/target/classes;
D:/APT/projects/apt-examples/calculator/calculator-ear/target/test-classes;
D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT.jar;
D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-servlets/1.1-SNAPSHOT/calculator-servlets-1.1-SNAPSHOT.jar;
D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-ejb/1.1-SNAPSHOT/calculator-ejb-1.1-SNAPSHOT-client.jar;
D:/PROFILES/allenj4/.m2/repository/javax/j2ee/j2ee/1.4/j2ee-1.4.jar;
D:/PROFILES/allenj4/.m2/repository/tomcat/jasper-runtime/5.5.12/jasper-runtime-5.5.12.jar;
D:/PROFILES/allenj4/.m2/repository/com/fujitsu/fs/apt/examples/calculator/calculator-engine/1.1-SNAPSHOT/calculator-engine-1.1-SNAPSHOT.jar'
-protected
-sourcepath
'D:/APT/projects/apt-examples/calculator/calculator-engine/src/test/java'
-author
-charset
'ISO-8859-1'
-d
'D:/APT/projects/apt-examples/calculator/calculator-root/target/site/testapidocs'
-doctitle
'Calculator 1.1-SNAPSHOT Test API'
-linkoffline
'http://java.sun.com/j2se/1.4.2/docs/api' null
-use
-version
-windowtitle
'Calculator 1.1-SNAPSHOT Test API'
{code}
Which of course gives us:
{code}
[INFO] Javadoc Warnings
[WARNING]
D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:6:
package junit.framework does not exist
[WARNING] import junit.framework.TestCase;
[WARNING] ^
[WARNING]
D:\APT\projects\apt-examples\calculator\calculator-engine\src\test\java\com\fujitsu\calculator\engine\CalculatorTest.java:13:
cannot find symbol
[WARNING] symbol: class TestCase
[WARNING] extends TestCase
[WARNING] ^
{code}
--
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: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data
[ http://jira.codehaus.org/browse/MCLOVER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCLOVER-80: -- Attachment: MCLOVER-80.diff > aggregate is not respecting the true module hierarchy and creates merged > databases containing non-sibling data > -- > > Key: MCLOVER-80 > URL: http://jira.codehaus.org/browse/MCLOVER-80 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: John Allen > Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, > MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff > > > The reactor contains a very deep multi-project multi-module structure. We > would expect the aggregation to only go up the family tree and not pollute > across the ancestors. > A-->B-->C-->D > A-->B-->E > A-->Q-->P-->R > A-->Q-->P-->S > We would expect A to contain all the merged data but not to find that in P we > have data from C and D. -- 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: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data
[ http://jira.codehaus.org/browse/MCLOVER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103541 ] John Allen edited comment on MCLOVER-80 at 7/29/07 6:46 AM: it has been observed that a module hierarchy is very different to the project inheritance hierarchy. This version of the patch thus fixes aggregate such that: Aggregate no longer aggregates all clover databases to all other clover databases regardless of their position within the *module* hierarchy. This is the original issue that ticket was raised to address. The previous patch attempted to do the same thing but, critically, used the inheritance hierarchy and not the module hierarchy. was: it has been observed that a module hierarchy is very different to the project inheritance hierarchy. This version of the patch thus fixes aggregate such that: *Aggregate no longer aggregates all clover databases to all other clover databases regardless of their position within the *module* hierarchy. This is the original issue that ticket was raised to address. The previous patch attempted to do the same thing but, critically, used the inheritance hierarchy and not the module hierarchy. > aggregate is not respecting the true module hierarchy and creates merged > databases containing non-sibling data > -- > > Key: MCLOVER-80 > URL: http://jira.codehaus.org/browse/MCLOVER-80 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: John Allen > Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, > MCLOVER-80.diff, MCLOVER-80.diff > > > The reactor contains a very deep multi-project multi-module structure. We > would expect the aggregation to only go up the family tree and not pollute > across the ancestors. > A-->B-->C-->D > A-->B-->E > A-->Q-->P-->R > A-->Q-->P-->S > We would expect A to contain all the merged data but not to find that in P we > have data from C and D. -- 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: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data
[ http://jira.codehaus.org/browse/MCLOVER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCLOVER-80: -- Attachment: MCLOVER-80.diff it has been observed that a module hierarchy is very different to the project inheritance hierarchy. This version of the patch thus fixes aggregate such that: *Aggregate no longer aggregates all clover databases to all other clover databases regardless of their position within the *module* hierarchy. This is the original issue that ticket was raised to address. The previous patch attempted to do the same thing but, critically, used the inheritance hierarchy and not the module hierarchy. > aggregate is not respecting the true module hierarchy and creates merged > databases containing non-sibling data > -- > > Key: MCLOVER-80 > URL: http://jira.codehaus.org/browse/MCLOVER-80 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: John Allen > Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, > MCLOVER-80.diff, MCLOVER-80.diff > > > The reactor contains a very deep multi-project multi-module structure. We > would expect the aggregation to only go up the family tree and not pollute > across the ancestors. > A-->B-->C-->D > A-->B-->E > A-->Q-->P-->R > A-->Q-->P-->S > We would expect A to contain all the merged data but not to find that in P we > have data from C and D. -- 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: (MCHANGELOG-74) Combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, MCHANGELOG-72, MCHANGELOG-73
[ http://jira.codehaus.org/browse/MCHANGELOG-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-74: - Attachment: MCHANGELOG-69,70,71,72,73.patch previous patch was missing a call to sinkAuthorNames() in doChangeSetDetails() methods and thus did not print active links for the developer names (was a patch error) > Combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, > MCHANGELOG-72, MCHANGELOG-73 > > > Key: MCHANGELOG-74 > URL: http://jira.codehaus.org/browse/MCHANGELOG-74 > Project: Maven 2.x Changelog Plugin > Issue Type: Task >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-69,70,71,72,73.patch, > MCHANGELOG-69,70,71,72,73.patch, MCHANGELOG-69,70,71,72,73.patch > > > This is a combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, > MCHANGELOG-72, MCHANGELOG-73. I have produced individual patches for each > issue so that the code can easily be reviewed by the committers and then this > combined patch to allow all those mini-patches to be easily applied against > the trunk. > I hope this is considered ok as I could not think of a better way to make the > job of the committer easy, plus it was right pain to do > All updates made against trunk revision 560535. > Note there are two change in this combined patch to the individual patches - > due to MCHANGELOG-68 I had switched on ignore test failures - and being an > idiot had not kept track of how many unit tests were failing. To my horror I > noticed that loads of the tests were failing but not due to functional issues > as such but instead due to the NPEs being raised because a lack of injected > values. I have since changed the code to, where appropriate, check for nulls > and thus all the unit tests NPEs have gone away. Sorry I should have had my > eye on this right from the start. -- 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] Created: (MJAVADOC-139) NPE out of AbstractJavadocMojo::getSourcePaths() on multimodule project using aggregate
NPE out of AbstractJavadocMojo::getSourcePaths() on multimodule project using
aggregate
---
Key: MJAVADOC-139
URL: http://jira.codehaus.org/browse/MJAVADOC-139
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Reporter: John Allen
My main concern is this area of the code:
AbstractJavadocMojo::getSourcePaths()
{code}
/**
* Method to get the source paths. If no source path is specified in the
parameter, the compile source roots
* of the project will be used.
*
* @return a List of the project source paths
*/
protected List getSourcePaths()
{
List sourcePaths;
if ( StringUtils.isEmpty( sourcepath ) )
{
sourcePaths = new ArrayList( getProjectSourceRoots( project ) );
if ( project.getExecutionProject() != null )
{
sourcePaths.addAll( getExecutionProjectSourceRoots( project ) );
}
if ( getJavadocDirectory() != null )
{
File javadocDir = getJavadocDirectory();
if ( javadocDir.exists() && javadocDir.isDirectory() )
{
sourcePaths.add( getJavadocDirectory().getAbsolutePath() );
}
}
if ( aggregate && project.isExecutionRoot() )
{
for ( Iterator i = reactorProjects.iterator(); i.hasNext(); )
{
MavenProject subProject = (MavenProject) i.next();
if ( subProject != project )
{
List sourceRoots = getProjectSourceRoots( subProject );
{code}
*HERE WE CHECK IF subProject.getExecutionProject() IS NOT EQUAL TO NULL*
{code}
if ( subProject.getExecutionProject() != null )
{
sourceRoots.addAll( getExecutionProjectSourceRoots(
subProject ) );
}
ArtifactHandler artifactHandler =
subProject.getArtifact().getArtifactHandler();
if ( "java".equals( artifactHandler.getLanguage() ) )
{
sourcePaths.addAll( sourceRoots );
}
{code}
*BUT NOW WE TRY AND DEREFERENCE subProject.getExecutionProject() REGARDLESS -
RESULTS IN NPE*
{code}
String javadocDirRelative = PathUtils.toRelative(
project.getBasedir(), getJavadocDirectory().getAbsolutePath() );
File javadocDir = new File(
subProject.getExecutionProject().getBasedir(), javadocDirRelative );
if ( javadocDir.exists() && javadocDir.isDirectory() )
{
sourcePaths.add( javadocDir.getAbsolutePath() );
}
}
}
}
sourcePaths = pruneSourceDirs( sourcePaths );
}
else
{
sourcePaths = new ArrayList( Arrays.asList( sourcepath.split( "[;]"
) ) );
if ( getJavadocDirectory() != null )
{
sourcePaths.add( getJavadocDirectory().getAbsolutePath() );
}
sourcePaths = pruneSourceDirs( sourcePaths );
}
return sourcePaths;
}
{code}
--
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: (MCHANGELOG-70) Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs
[ http://jira.codehaus.org/browse/MCHANGELOG-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-70: - Attachment: MCHANGELOG-70,71,72.patch fixes NPEs in unit tests due to a lack of injected parameters. > Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM > message to be mapped to real URLs > > > Key: MCHANGELOG-70 > URL: http://jira.codehaus.org/browse/MCHANGELOG-70 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-70,71,72.patch, MCHANGELOG-70,71,72.patch, > MCHANGELOG-70.patch, MCHANGELOG-70.patch, MCHANGELOG-70.patch > > > Eclipse Mylyn, plus other good behaviours (see [JIRA Commit Acceptance > Plugin|http://confluence.atlassian.com/display/JIRAEXT/Commit+Acceptance+Plugin]) > make it necessary to quote a task upon check-in. These task IDs can easily > be mapped to URLs using simple regex pattern rules that can be defined in the > plugin config. -- 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: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE
[ http://jira.codehaus.org/browse/MCHANGELOG-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-71: - Attachment: MCHANGELOG-71.patch changed base path of patch > Support a %REV% in displayFileDetailUrl in the same way we support %FILE > > > Key: MCHANGELOG-71 > URL: http://jira.codehaus.org/browse/MCHANGELOG-71 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-71.patch, MCHANGELOG-71.patch > > > Reports are historical and by providing this we can keep the links to actual > revisions of the files. -- 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: (MCHANGELOG-70) Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs
[ http://jira.codehaus.org/browse/MCHANGELOG-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-70: - Attachment: MCHANGELOG-70.patch fixes unit tests failures from NPEs due to a lack of parameter injected values. > Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM > message to be mapped to real URLs > > > Key: MCHANGELOG-70 > URL: http://jira.codehaus.org/browse/MCHANGELOG-70 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-70,71,72.patch, MCHANGELOG-70.patch, > MCHANGELOG-70.patch, MCHANGELOG-70.patch > > > Eclipse Mylyn, plus other good behaviours (see [JIRA Commit Acceptance > Plugin|http://confluence.atlassian.com/display/JIRAEXT/Commit+Acceptance+Plugin]) > make it necessary to quote a task upon check-in. These task IDs can easily > be mapped to URLs using simple regex pattern rules that can be defined in the > plugin config. -- 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: (MCHANGELOG-69) Print developer names regardless of whether they're listed in the POM
[ http://jira.codehaus.org/browse/MCHANGELOG-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-69: - Attachment: MCHANGELOG-69,73.patch fixes NPE in unit tests from a lack of valid injected > Print developer names regardless of whether they're listed in the POM > - > > Key: MCHANGELOG-69 > URL: http://jira.codehaus.org/browse/MCHANGELOG-69 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: 2.2 >Reporter: John Allen > Attachments: MCHANGELOG-69,73.patch, MCHANGELOG-69,73.patch > > > It seems a waste to throw away good information from the SCM report just > because a developer is not listed in the projects , > lets just print the name from the SCM report (userid) if we cant find them in > the project. -- 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] Created: (MCHANGELOG-74) Combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, MCHANGELOG-72, MCHANGELOG-73
Combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, MCHANGELOG-72, MCHANGELOG-73 Key: MCHANGELOG-74 URL: http://jira.codehaus.org/browse/MCHANGELOG-74 Project: Maven 2.x Changelog Plugin Issue Type: Task Affects Versions: 2.1 Reporter: John Allen Attachments: MCHANGELOG-69,70,71,72,73.patch This is a combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, MCHANGELOG-72, MCHANGELOG-73. I have produced individual patches for each issue so that the code can easily be reviewed by the committers and then this combined patch to allow all those mini-patches to be easily applied against the trunk. I hope this is considered ok as I could not think of a better way to make the job of the committer easy, plus it was right pain to do All updates made against trunk revision 560535. Note there are two change in this combined patch to the individual patches - due to MCHANGELOG-68 I had switched on ignore test failures - and being an idiot had not kept track of how many unit tests were failing. To my horror I noticed that loads of the tests were failing but not due to functional issues as such but instead due to the NPEs being raised because a lack of injected values. I have since changed the code to, where appropriate, check for nulls and thus all the unit tests NPEs have gone away. Sorry I should have had my eye on this right from the start. -- 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: (MCHANGELOG-74) Combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, MCHANGELOG-72, MCHANGELOG-73
[ http://jira.codehaus.org/browse/MCHANGELOG-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-74: - Attachment: MCHANGELOG-69,70,71,72,73.patch removed unnecessary change to ChangeLogReportTest > Combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, > MCHANGELOG-72, MCHANGELOG-73 > > > Key: MCHANGELOG-74 > URL: http://jira.codehaus.org/browse/MCHANGELOG-74 > Project: Maven 2.x Changelog Plugin > Issue Type: Task >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-69,70,71,72,73.patch, > MCHANGELOG-69,70,71,72,73.patch > > > This is a combined patch for MCHANGELOG-69, MCHANGELOG-70, MCHANGELOG-71, > MCHANGELOG-72, MCHANGELOG-73. I have produced individual patches for each > issue so that the code can easily be reviewed by the committers and then this > combined patch to allow all those mini-patches to be easily applied against > the trunk. > I hope this is considered ok as I could not think of a better way to make the > job of the committer easy, plus it was right pain to do > All updates made against trunk revision 560535. > Note there are two change in this combined patch to the individual patches - > due to MCHANGELOG-68 I had switched on ignore test failures - and being an > idiot had not kept track of how many unit tests were failing. To my horror I > noticed that loads of the tests were failing but not due to functional issues > as such but instead due to the NPEs being raised because a lack of injected > values. I have since changed the code to, where appropriate, check for nulls > and thus all the unit tests NPEs have gone away. Sorry I should have had my > eye on this right from the start. -- 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: (MCHANGELOG-73) Print developer names in the change report for known developers and make them links to the team page.
[ http://jira.codehaus.org/browse/MCHANGELOG-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-73: - Attachment: MCHANGELOG-69,73.patch Patch against trunk, 560535. It's combined with the MCHANGELOG-69 as it was almost illogical not to do so (sorry if this is a pain). A combined patch for all enhancements listed in MCHANGELOG-69 to MCHANGELO-73 will also be provided for ease of application. > Print developer names in the change report for known developers and make them > links to the team page. > - > > Key: MCHANGELOG-73 > URL: http://jira.codehaus.org/browse/MCHANGELOG-73 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Reporter: John Allen > Attachments: MCHANGELOG-69,73.patch > > > If we know who the developer is we can create a link in the same fashion as > we do for the Developer Activity report. -- 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: (MCHANGELOG-69) Print developer names regardless of whether they're listed in the POM
[ http://jira.codehaus.org/browse/MCHANGELOG-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-69: - Attachment: MCHANGELOG-69,73.patch Patch against trunk, 560535. It's combined with the MCHANGELOG-71 as it was almost illogical not to do so (sorry if this is a pain). A combined patch for all enhancements listed in MCHANGELOG-69 through to MCHANGELOG-73 will also be provided for ease of application. > Print developer names regardless of whether they're listed in the POM > - > > Key: MCHANGELOG-69 > URL: http://jira.codehaus.org/browse/MCHANGELOG-69 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: 2.2 >Reporter: John Allen > Attachments: MCHANGELOG-69,73.patch > > > It seems a waste to throw away good information from the SCM report just > because a developer is not listed in the projects , > lets just print the name from the SCM report (userid) if we cant find them in > the project. -- 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] Created: (MCHANGELOG-73) Print developer names in the change report for known developers and make them links to the team page.
Print developer names in the change report for known developers and make them links to the team page. - Key: MCHANGELOG-73 URL: http://jira.codehaus.org/browse/MCHANGELOG-73 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Reporter: John Allen If we know who the developer is we can create a link in the same fashion as we do for the Developer Activity report. -- 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: (MCHANGELOG-72) Provide a way to make the changeset revision number used in the changelog report an active link
[
http://jira.codehaus.org/browse/MCHANGELOG-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103502
]
John Allen commented on MCHANGELOG-72:
--
See http://jira.codehaus.org/browse/MCHANGELOG-70#action_103500 for a combined
patch
> Provide a way to make the changeset revision number used in the changelog
> report an active link
> ---
>
> Key: MCHANGELOG-72
> URL: http://jira.codehaus.org/browse/MCHANGELOG-72
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: John Allen
> Attachments: MCHANGELOG-72.patch
>
>
> This is different a file revision, depending on the SCM being used. For
> instance if the user is using SVN then the changeset, which is identified by
> the revision number, contains all the files that were committed as part of
> that check-in. Tools such as FishEye and like let you browse changesets as
> well as specific files so my suggestion is to provide a new option that works
> in a similar fashion to the displayFileDetailUrl, called
> displayChangeSetDetailUrl.
> {code}
> /**
> * A template string that is used to create the changeset URL.
> *
> * If not defined not change set link will be created
> *
> * There is one special tokens that you can use in your template:
> *
> * %REV% - this is the changset revision
> *
> *
> * Example:
> *
> http://fisheye.sourceforge.net/changelog/a-project/?cs=%REV%
> *
> *
> * Note: If you don't supply the %REV% token in your
> template,
> * the revision will simply be appended to your template URL.
> *
> *
> * @parameter expression="${displayChangeSetDetailUrl}"
> */
> protected String displayChangeSetDetailUrl;
> {code}
> Patch to 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: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE
[ http://jira.codehaus.org/browse/MCHANGELOG-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103501 ] John Allen commented on MCHANGELOG-71: -- See http://jira.codehaus.org/browse/MCHANGELOG-70#action_103500 for a combined patch > Support a %REV% in displayFileDetailUrl in the same way we support %FILE > > > Key: MCHANGELOG-71 > URL: http://jira.codehaus.org/browse/MCHANGELOG-71 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-71.patch > > > Reports are historical and by providing this we can keep the links to actual > revisions of the files. -- 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: (MCHANGELOG-70) Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs
[ http://jira.codehaus.org/browse/MCHANGELOG-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-70: - Attachment: MCHANGELOG-70,71,72.patch Combined patch for MCHANGELOG-70, MCHANGELOG-71 and MCHANGELOG-72 - much easier to apply once the individuals have been reviewed and accepted. > Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM > message to be mapped to real URLs > > > Key: MCHANGELOG-70 > URL: http://jira.codehaus.org/browse/MCHANGELOG-70 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-70,71,72.patch, MCHANGELOG-70.patch, > MCHANGELOG-70.patch > > > Eclipse Mylyn, plus other good behaviours (see [JIRA Commit Acceptance > Plugin|http://confluence.atlassian.com/display/JIRAEXT/Commit+Acceptance+Plugin]) > make it necessary to quote a task upon check-in. These task IDs can easily > be mapped to URLs using simple regex pattern rules that can be defined in the > plugin config. -- 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: (MCHANGELOG-70) Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs
[
http://jira.codehaus.org/browse/MCHANGELOG-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Allen updated MCHANGELOG-70:
-
Attachment: MCHANGELOG-70.patch
Mistake in the 'ticketLinkRegexPattern' default value - an extra escape
character was required, i.e.
{code}
* @parameter expression="${ticketLinkRegexPattern}"
default-value="[a-zA-Z]{2,}-\d+"
{code}
should have been:
{code}
* @parameter expression="${ticketLinkRegexPattern}"
default-value="[a-zA-Z]{2,}-\\d+"
{code}
> Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM
> message to be mapped to real URLs
>
>
> Key: MCHANGELOG-70
> URL: http://jira.codehaus.org/browse/MCHANGELOG-70
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: John Allen
> Attachments: MCHANGELOG-70.patch, MCHANGELOG-70.patch
>
>
> Eclipse Mylyn, plus other good behaviours (see [JIRA Commit Acceptance
> Plugin|http://confluence.atlassian.com/display/JIRAEXT/Commit+Acceptance+Plugin])
> make it necessary to quote a task upon check-in. These task IDs can easily
> be mapped to URLs using simple regex pattern rules that can be defined in the
> plugin config.
--
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: (MCHANGELOG-70) Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs
[
http://jira.codehaus.org/browse/MCHANGELOG-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Allen updated MCHANGELOG-70:
-
Attachment: MCHANGELOG-70.patch
Patch provides two new options:
{code}
/**
* A pattern used to identify 'issue tracker' IDs such as those used by
JIRA,
* Bugzilla and alike in the SCM commit messages. Any matched patterns
* are replaced with ticketLinkUrl URL. The default
* value is a JIRA-style ticket identification pattern.
*
* @parameter expression="${ticketLinkRegexPattern}"
default-value="[a-zA-Z]{2,}-\d+"
* @required
*/
private String ticketLinkRegexPattern;
/**
* The issue tracker URL used in replacing any matched
ticketLinkRegexPattern
* found in the SCM commit messages. The default is URL is the codehaus JIRA
* URL. If %TICKET% if found in the URL it is replaced with the matched
ticket ID,
* otherwise the matched ticket ID is appended to the URL.
*
* @parameter expression="${ticketLinkUrl}"
default-value="http://jira.codehaus.org/browse/%TICKET%";
* @required
*/
private String ticketLinkUrl;
{code}
Which, if defined, will replace any matching 'ticket identifiers' found in the
commit messages with links to the ticket system based on the 'ticketLinkUrl'
template string.
Patch generated against trunk, revision 560535.
Combined patch for MCHANGELOG-70, MCHANGELOG-71 and MCHANGELOG-72 to follow.
> Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM
> message to be mapped to real URLs
>
>
> Key: MCHANGELOG-70
> URL: http://jira.codehaus.org/browse/MCHANGELOG-70
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: John Allen
> Attachments: MCHANGELOG-70.patch
>
>
> Eclipse Mylyn, plus other good behaviours (see [JIRA Commit Acceptance
> Plugin|http://confluence.atlassian.com/display/JIRAEXT/Commit+Acceptance+Plugin])
> make it necessary to quote a task upon check-in. These task IDs can easily
> be mapped to URLs using simple regex pattern rules that can be defined in the
> plugin config.
--
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: (MCHANGELOG-72) Provide a way to make the changeset revision number used in the changelog report an active link
[
http://jira.codehaus.org/browse/MCHANGELOG-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103497
]
John Allen commented on MCHANGELOG-72:
--
ps. codehaus JIRA administrator - you may wish to consider letting the reporter
of a ticket having the 'Edit Permission' as I can not mark these tickets as
'Patch attached' even though i created the issues and have attached patches
(just didnt do it all at the same time)
> Provide a way to make the changeset revision number used in the changelog
> report an active link
> ---
>
> Key: MCHANGELOG-72
> URL: http://jira.codehaus.org/browse/MCHANGELOG-72
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: John Allen
> Attachments: MCHANGELOG-72.patch
>
>
> This is different a file revision, depending on the SCM being used. For
> instance if the user is using SVN then the changeset, which is identified by
> the revision number, contains all the files that were committed as part of
> that check-in. Tools such as FishEye and like let you browse changesets as
> well as specific files so my suggestion is to provide a new option that works
> in a similar fashion to the displayFileDetailUrl, called
> displayChangeSetDetailUrl.
> {code}
> /**
> * A template string that is used to create the changeset URL.
> *
> * If not defined not change set link will be created
> *
> * There is one special tokens that you can use in your template:
> *
> * %REV% - this is the changset revision
> *
> *
> * Example:
> *
> http://fisheye.sourceforge.net/changelog/a-project/?cs=%REV%
> *
> *
> * Note: If you don't supply the %REV% token in your
> template,
> * the revision will simply be appended to your template URL.
> *
> *
> * @parameter expression="${displayChangeSetDetailUrl}"
> */
> protected String displayChangeSetDetailUrl;
> {code}
> Patch to 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: (MCHANGELOG-72) Provide a way to make the changeset revision number used in the changelog report an active link
[
http://jira.codehaus.org/browse/MCHANGELOG-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Allen updated MCHANGELOG-72:
-
Attachment: MCHANGELOG-72.patch
Patch provides the described feature. Not wanting to combine multiple features
in one patch I have reverted my MCHANGELOG-71 change and created this patch
against trunk revision 560535. I will also provide a combined patch for all my
recent feature requests/suggestions to aid in applying them if they are all
deemed worthwhile (which of course I hope you do!)
> Provide a way to make the changeset revision number used in the changelog
> report an active link
> ---
>
> Key: MCHANGELOG-72
> URL: http://jira.codehaus.org/browse/MCHANGELOG-72
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: John Allen
> Attachments: MCHANGELOG-72.patch
>
>
> This is different a file revision, depending on the SCM being used. For
> instance if the user is using SVN then the changeset, which is identified by
> the revision number, contains all the files that were committed as part of
> that check-in. Tools such as FishEye and like let you browse changesets as
> well as specific files so my suggestion is to provide a new option that works
> in a similar fashion to the displayFileDetailUrl, called
> displayChangeSetDetailUrl.
> {code}
> /**
> * A template string that is used to create the changeset URL.
> *
> * If not defined not change set link will be created
> *
> * There is one special tokens that you can use in your template:
> *
> * %REV% - this is the changset revision
> *
> *
> * Example:
> *
> http://fisheye.sourceforge.net/changelog/a-project/?cs=%REV%
> *
> *
> * Note: If you don't supply the %REV% token in your
> template,
> * the revision will simply be appended to your template URL.
> *
> *
> * @parameter expression="${displayChangeSetDetailUrl}"
> */
> protected String displayChangeSetDetailUrl;
> {code}
> Patch to 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: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE
[ http://jira.codehaus.org/browse/MCHANGELOG-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCHANGELOG-71: - Attachment: MCHANGELOG-71.patch Patch provides displayFileRevDetailUrl option that can be used to create revision aware file links. Patch generated against trunk, 560535 > Support a %REV% in displayFileDetailUrl in the same way we support %FILE > > > Key: MCHANGELOG-71 > URL: http://jira.codehaus.org/browse/MCHANGELOG-71 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Allen > Attachments: MCHANGELOG-71.patch > > > Reports are historical and by providing this we can keep the links to actual > revisions of the files. -- 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] Created: (MCHANGELOG-72) Provide a way to make the changeset revision number used in the changelog report an active link
Provide a way to make the changeset revision number used in the changelog
report an active link
---
Key: MCHANGELOG-72
URL: http://jira.codehaus.org/browse/MCHANGELOG-72
Project: Maven 2.x Changelog Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: John Allen
This is different a file revision, depending on the SCM being used. For
instance if the user is using SVN then the changeset, which is identified by
the revision number, contains all the files that were committed as part of that
check-in. Tools such as FishEye and like let you browse changesets as well as
specific files so my suggestion is to provide a new option that works in a
similar fashion to the displayFileDetailUrl, called displayChangeSetDetailUrl.
{code}
/**
* A template string that is used to create the changeset URL.
*
* If not defined not change set link will be created
*
* There is one special tokens that you can use in your template:
*
* %REV% - this is the changset revision
*
*
* Example:
* http://fisheye.sourceforge.net/changelog/a-project/?cs=%REV%
*
*
* Note: If you don't supply the %REV% token in your
template,
* the revision will simply be appended to your template URL.
*
*
* @parameter expression="${displayChangeSetDetailUrl}"
*/
protected String displayChangeSetDetailUrl;
{code}
Patch to 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: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE
[ http://jira.codehaus.org/browse/MCHANGELOG-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103494 ] John Allen commented on MCHANGELOG-71: -- Looking at this further I have implemented this feature with a new parameter called displayFileRevisionDetailUrl. If not defined it defaults to displayFileDetailUrl and thus provides backward compatibility. Patch forthcoming > Support a %REV% in displayFileDetailUrl in the same way we support %FILE > > > Key: MCHANGELOG-71 > URL: http://jira.codehaus.org/browse/MCHANGELOG-71 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Allen > > Reports are historical and by providing this we can keep the links to actual > revisions of the files. -- 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: (MJAVADOC-137) javadoc:javadoc always runs as "aggregator"
[ http://jira.codehaus.org/browse/MJAVADOC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103491 ] John Allen commented on MJAVADOC-137: - My observation should have been that when report MOJOs are run from the site plugin they do not honour @aggregator declaration, this is what brett is confirming [here|http://jira.codehaus.org/browse/MNG-2184#action_62425]. Running the MOJO external to site (i.e. via the command line javadoc:javadoc) appears, according to your experiences, to allow the MOJO to run as an aggregator. I would raise this issue on the @dev list and ask why has this MOJO been made an @aggregator, seems like a mistake to me too. As a workaround either drop back a version or build your own patched version of the plugin? > javadoc:javadoc always runs as "aggregator" > --- > > Key: MJAVADOC-137 > URL: http://jira.codehaus.org/browse/MJAVADOC-137 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Peter Hendriks >Priority: Critical > > In version 2.2, javadoc aggregation was configurable using the configuration > property "aggregate". In version 2.3, all javadoc goals got the @aggregator > attribute added to its mojos (through a change in > org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now > always run aggregated regardless of the configuration setting. This breaks > our build as we require non-aggregated javadoc execution in our multi-module > poms. Please fix this so this is once again configurable and backwards > compatible with previous versions of the javadoc plug-in. -- 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] Created: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE
Support a %REV% in displayFileDetailUrl in the same way we support %FILE Key: MCHANGELOG-71 URL: http://jira.codehaus.org/browse/MCHANGELOG-71 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.1, 2.2 Reporter: John Allen Reports are historical and by providing this we can keep the links to actual revisions of the files. -- 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] Created: (MCHANGELOG-70) Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs
Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs Key: MCHANGELOG-70 URL: http://jira.codehaus.org/browse/MCHANGELOG-70 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: John Allen Eclipse Mylyn, plus other good behaviours (see [JIRA Commit Acceptance Plugin|http://confluence.atlassian.com/display/JIRAEXT/Commit+Acceptance+Plugin]) make it necessary to quote a task upon check-in. These task IDs can easily be mapped to URLs using simple regex pattern rules that can be defined in the plugin config. -- 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] Created: (MCHANGELOG-69) Print developer names regardless of whether they're listed in the POM
Print developer names regardless of whether they're listed in the POM - Key: MCHANGELOG-69 URL: http://jira.codehaus.org/browse/MCHANGELOG-69 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: 2.2 Reporter: John Allen It seems a waste to throw away good information from the SCM report just because a developer is not listed in the projects , lets just print the name from the SCM report (userid) if we cant find them in the project. -- 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] Created: (MCHANGELOG-68) testReadFile unit test timebased comparisons fail
testReadFile unit test timebased comparisons fail
-
Key: MCHANGELOG-68
URL: http://jira.codehaus.org/browse/MCHANGELOG-68
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: 2.0.7
Reporter: John Allen
The unit tests in ChangeLogTest that test the changeset file for time
comparisons such as:
{code}
ChangeSet changeSet = (ChangeSet) changelogSets.getChangeSets().get( 0
);
Calendar cal = Calendar.getInstance(); // new cal with default TZ
cal.set( 1977, 7, 6, 5, 30, 0); // expected date from min-changelog.xml
cal.set( Calendar.MILLISECOND, 0);
assertEquals( "Test changelog 1 set 1 date/time",
cal.getTime().getTime(), changeSet.getDate().getTime() );
{code}
Fail on my UK GMT machine with trace:
{code}
junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time
expected:<23967180> but was:<23968620>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:136)
at
org.apache.maven.plugin.changelog.ChangeLogTest.testReadFile(ChangeLogTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
{code}
--
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: (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_103404
]
John Allen commented on MSITE-129:
--
Kenney, how can we go about dealing with these two cases?
* A user wishes to have all the modules appear.
Okay so I guess with the tag being called then this is what it
was originally intended to do and the reactor based code should be changed to
only find the modules from the reactor, not the inheriting projects (as it does
at the moment).
The benefits to using the reactor is that it's quick and the projects are fully
interpolated. If there's no reactor we try and build the models from the
fileystem module POMs. I'm not sure how interpolated they are, ie if the module
has ${} values in it are they evaluated? (didnt used to be the case but could
be now). If there are no filesystem modules available then it's a pure nasty
hack of setting the module project's name and url to be the value found in the
root project's element, which for flat multimodule type
scenarios will be "../somename" ( ! )
* A user wishes to have the children appear in the site, regardless of the
modules.
This is what users like me want. I guess a configuration option could be used
to distinguish this behaviour rather than a new site.xml element. Either way
this is easy for the reactor based 'child project's find but for the mvn -N
situations one would need to create all the module projects from their file
system pom.xml files and then check if their parent clauses match the current
project.
Actually that doesn't sound to be bad to me. Thoughts?
> 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] Updated: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data
[ http://jira.codehaus.org/browse/MCLOVER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCLOVER-80: -- Attachment: MCLOVER-80.diff After discussion it appears that some people would like aggregate to include all the projects within the reactor, regardless of their inheritance relationship to the parent project (i.e. the existing behaviour) and others would like the inheritance hierarchy to be honoured in aggregation. This latest patch supports both these configurations with the addition of a new configuration option 'aggregateOnlyChildren'. > aggregate is not respecting the true module hierarchy and creates merged > databases containing non-sibling data > -- > > Key: MCLOVER-80 > URL: http://jira.codehaus.org/browse/MCLOVER-80 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: John Allen > Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, > MCLOVER-80.diff > > > The reactor contains a very deep multi-project multi-module structure. We > would expect the aggregation to only go up the family tree and not pollute > across the ancestors. > A-->B-->C-->D > A-->B-->E > A-->Q-->P-->R > A-->Q-->P-->S > We would expect A to contain all the merged data but not to find that in P we > have data from C and D. -- 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: (MJAVADOC-137) javadoc:javadoc always runs as "aggregator"
[ http://jira.codehaus.org/browse/MJAVADOC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103388 ] John Allen commented on MJAVADOC-137: - If you run the javadoc plugin as report then the @aggregator is ignored (see MNG-2184), I have removed the @aggregator from my local version of the plugin and it passes all its tests but i expect the JavadocJarMojo might suffer (haven't tested yet and i would have too look at the code some more). Personally I cant see why one would want any of the javadoc mojo's functionality to run as an aggregator. Note the 'aggregate' report mojo option is actually implemented inside the mojo, ie. the report exits if it's already been run in the reactor and aggregate is true. > javadoc:javadoc always runs as "aggregator" > --- > > Key: MJAVADOC-137 > URL: http://jira.codehaus.org/browse/MJAVADOC-137 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Peter Hendriks >Priority: Critical > > In version 2.2, javadoc aggregation was configurable using the configuration > property "aggregate". In version 2.3, all javadoc goals got the @aggregator > attribute added to its mojos (through a change in > org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now > always run aggregated regardless of the configuration setting. This breaks > our build as we require non-aggregated javadoc execution in our multi-module > poms. Please fix this so this is once again configurable and backwards > compatible with previous versions of the javadoc plug-in. -- 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: (MSITE-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103374 ] John Allen commented on MSITE-132: -- Guess I'm not explaining myself very well :) Re the name being used to create the path in the stage mojo when the POM has no distributionManagement section defined - that sounds like a mistake to me and thus my [comment to Denis|http://jira.codehaus.org/browse/MSITE-132#action_103351]. Additionally re Jorg's statements about what and how stage should work. It works based off maven's distributionManagement section to achieve the use case of 'mirroring' or staging a deployment to a local file-system location for local review before real deployment to the project's published location is performed. It does that just fine and is used by lots of users. Additionally, being a core plugin, it is designed to support the main Maven usage scenarios, if you don't do it that way, or want to do it another way, you are of course free to create your own plugin. For a wider discussion about Maven's usage including it's plugins i recommend the [Maven Users Mailing List|http://www.nabble.com/Maven---Users-f178.html] Lastly, I didn't write these plugins so have absolutely no say on their design but as an OSS project we can all contribute to Maven's improvement. Start on the mailing lists and see how others use it, you never know maybe everyone will agree and the core developers will consider a redesign. > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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: (MNG-367) best practices: multi-user installation
[ http://jira.codehaus.org/browse/MNG-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103359 ] John Allen commented on MNG-367: Re installers - We deploy our developers java environment via a nice looking NSIS installer (all built using m2 of course) Anyway, that puts in place the m2, then runs (optionally) the JDK, SVN, Tortoise installers and sets up a correct m2/conf/settings and $HOME/.m2 as well as defines MVN_OPTS to ensure the correct keystore info is passed to the JVM so that webdav deployments work. Not hard. And because of the per user env and HOME setup works for multiple users on the same box. > best practices: multi-user installation > --- > > Key: MNG-367 > URL: http://jira.codehaus.org/browse/MNG-367 > Project: Maven 2 > Issue Type: Task > Components: Design, Patterns & Best Practices >Reporter: Brett Porter >Priority: Trivial > Fix For: 2.1.x > > > so we need to support: > - read only install > - setttings in the installation > - works with just the m2 executable in the path (no M2_HOME setting) > - possibility of a remote settings file for standalone installs, force a > regular (daily) check when online to push updates > encourage: > - storing of install on a shared, read only drive > - possibly use a CVS checkout > - may want to integrate with existing deployment policies (eg an MSI that can > be easily deployed) -- 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: (MNG-41) best practices: site management
[
http://jira.codehaus.org/browse/MNG-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103358
]
John Allen edited comment on MNG-41 at 7/26/07 6:54 AM:
I know I've been banging this drum from day one so I'm obviously off 'Maven
message' in this regard but as far as i can see a maven site is just another
type of artifact generated by a project. It has all the same aspects, couplings
et al as the other products of a project and should not be seen as a convenient
way to knock up your OSS web pages.
Corporate use of a maven project site is to render the human readable view on
the project's constructs (UML models, javadoc, analysis reports, and yes even
user guides) and is thus directly coupled to the version that generated it.
This then leads to POMs with project.urls and distro.site.urls like this:
{code}
projects.examples.site.deployment
Examples: Site Deployment
dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
${project.url}
http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
{code}
Thus all our deployed sites attempt to maintain the rigour of a true version
controlled namespace.
How we then map to the 'latest' of these is another point, and again, one I
have written about before; currently we do this, in the absence of real
repository, with server side scripting (aka PHP hack) as there is no real
'release' semantic and we can't really afford to go creating one at the moment.
Hope I'm not missing the point and slipping into rant mode (I'm in bed with
flu!)
Re the staging - we don't currently do that in the same public way you have to.
At the moment we simply 'export' the SNAPSHOTs and get internal peer review
from those (version info is not lost on ours) and if we had to do
release:prepare then i would have the distro locations to point to a real
sandbox staging environment and get QA acceptance there before performing a
real release.
was:
I know I've been banging this drum from day one so I'm obviously off 'Maven
message' in this regard but as far as i can see a maven site is just another
type of artifact generated by a project. It has all the same aspects, couplings
et al as the other products of a project and should not be seen as a convenient
way to knock up your OSS web pages.
Corporate use of a maven project site is to render the human readable view on
the project's constructs (UML models, javadoc, analysis reports, and yes even
user guides) and is thus directly coupled to the version that generated it.
This then leads to POMs with project.urls and distro.site.urls like this:
{code}
projects.examples.site.deployment
Examples: Site Deployment
dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
${project.url}
http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
{code}
Thus all our deployed sites attempt to maintain the rigour of a true version
controlled namespace.
How we then map to the 'latest' of these is another point, and again, one I
have written about before; currently we do this, in the absence of real
repository, with server side scripting (aka PHP hack) as there is no real
'release' semantic and we can't really afford to go creating one at the moment.
Hope I've not missing the point.
Re the staging - we don't currently do that in the same public way you have to.
At the moment we simply 'export' the SNAPSHOTs and get internal peer review
from those (version info is not lost on ours) and if we had to do
release:prepare then i would have the distro locations to point to a real
sandbox staging environment and get QA acceptance there before performing a
real release.
> best practices: site management
> ---
>
> Key: MNG-41
> URL: http://jira.codehaus.org/browse/MNG-41
> Project: Maven 2
> Issue Type: Task
> Components: Design, Patterns & Best Practices
>Reporter: Jason van Zyl
>Priority: Trivial
> Fix For: 2.1.x
>
>
> * How to deal with multiple versions of the site
> * How to deal with staging directories for the site (will require a change to
> the POM)
--
This message is automatically generated by JIRA.
-
If you thi
[jira] Commented: (MNG-41) best practices: site management
[
http://jira.codehaus.org/browse/MNG-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103358
]
John Allen commented on MNG-41:
---
I know I've been banging this drum from day one so I'm obviously off 'Maven
message' in this regard but as far as i can see a maven site is just another
type of artifact generated by a project. It has all the same aspects, couplings
et al as the other products of a project and should not be seen as a convenient
way to knock up your OSS web pages.
Corporate use of a maven project site is to render the human readable view on
the project's constructs (UML models, javadoc, analysis reports, and yes even
user guides) and is thus directly coupled to the version that generated it.
This then leads to POMs with project.urls and distro.site.urls like this:
{code}
projects.examples.site.deployment
Examples: Site Deployment
dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
${project.url}
http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
{code}
Thus all our deployed sites attempt to maintain the rigour of a true version
controlled namespace.
How we then map to the 'latest' of these is another point, and again, one I
have written about before; currently we do this, in the absence of real
repository, with server side scripting (aka PHP hack) as there is no real
'release' semantic and we can't really afford to go creating one at the moment.
Hope I've not missing the point.
Re the staging - we don't currently do that in the same public way you have to.
At the moment we simply 'export' the SNAPSHOTs and get internal peer review
from those (version info is not lost on ours) and if we had to do
release:prepare then i would have the distro locations to point to a real
sandbox staging environment and get QA acceptance there before performing a
real release.
> best practices: site management
> ---
>
> Key: MNG-41
> URL: http://jira.codehaus.org/browse/MNG-41
> Project: Maven 2
> Issue Type: Task
> Components: Design, Patterns & Best Practices
>Reporter: Jason van Zyl
>Priority: Trivial
> Fix For: 2.1.x
>
>
> * How to deal with multiple versions of the site
> * How to deal with staging directories for the site (will require a change to
> the POM)
--
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: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103352 ] John Allen commented on MSITE-159: -- I think something along the lines of 'convert URLs to relative URLs where possible' is sensible. Note that even relatives can be converted into better relatives. i.e. foo/bar/../../foo/bar/../ is the same as .. > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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: (MSITE-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103351 ] John Allen commented on MSITE-132: -- Denis, Ahh, it's only if you have no distroManagement section that it invents the path and this is why I've never seen it (we use a flat project structure and thus have to declare distroManagement and project.URL in every POM as maven's default assumptions are wrong for us). Seems a reasonable fix, will apply to my local patched plugin and play. > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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: (MSITE-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103350 ] John Allen commented on MSITE-132: -- Jorg, The logic of stage is fairly obvious. one is simulating the real world deployment, where projects and modules from the internet namespace are mapped to residing within a root node of a filesystem. Your expectation regarding what the site:stage plugin should do and how it should do it is wrong. Adjust your expectation and you will be happier. > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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: (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_103349
]
John Allen commented on MSITE-129:
--
Matt,
In regards to your structure. We are a massive information services company and
as such our 'apps' are produced by accounts and project teams in isolation of
each other and with lifecycles measured in years and 10s of years and as such
each one of our account/project 'apps' (itself consisting of multiple maven
modules) needs its own 'management' POM to setup where its SVN, CI, issue
tracker and distro management locations are, define plugin versions, and all
that good stuff. The only way to do this and have it used by all of the apps
modules is via inheritance. I guess I world is much more akin to a sourceforge
in as much as although we're one company we have many very independent projects
and the only way they can share their per-project settings amongst their
modules is via inheritance.
Horses for courses really.
> 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-195) Module navigation entries point to index.html not /index.html
[ http://jira.codehaus.org/browse/MSITE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103018 ] John Allen edited comment on MSITE-195 at 7/23/07 1:06 PM: --- Probably related to the way the modules have been found (ie via reactor, via filesystem or via the repository). In some cases (namely non-reactor) a module project wont be fully interpolated (and indeed inheritance composition may not have occured either, cant remember). Best to explicitly define URLs (and thus distroManagement.site.url) for all your projects if you do non-reactor based site builds was: Probably related to the way the modules have been found (ie via reactor, via filesystem or via the repository). > Module navigation entries point to index.html not /index.html > - > > Key: MSITE-195 > URL: http://jira.codehaus.org/browse/MSITE-195 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: Intel box running Windows XP >Reporter: Dale Chapman >Priority: Minor > > I am using Maven version 2.0.4 > I am experimenting with Maven to see if it will suit my organizations needs > and I have created a simple example that looks like the following: > App1Pom > + App1Ear > + App1Jar > (pom.xml snippet) > > App1Ear > App1Jar > > When I generate the site using mvn site, the "About" page for App1Pom shows > the two modules in the module section of the navigation, but neither has an > anchor. When I navigate to another section, both module entries will now > contain an anchor that points to index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > (project-info.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > When I generate the site using mvn site:stage, the navigation section > contains the correct entries of App1Ear/index.html and App1Jar/index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > I have tried to review the current bug list to see if this problem has > already been reported, but I was not able to see an entry that describes this > situation. If I have a usage problem please point me to some documentation > that can help me understand. > Thanks. > Dale Chapman. -- 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: (MSITE-195) Module navigation entries point to index.html not /index.html
[ http://jira.codehaus.org/browse/MSITE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103018 ] John Allen commented on MSITE-195: -- Probably related to the way the modules have been found (ie via reactor, via filesystem or via the repository). > Module navigation entries point to index.html not /index.html > - > > Key: MSITE-195 > URL: http://jira.codehaus.org/browse/MSITE-195 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: Intel box running Windows XP >Reporter: Dale Chapman >Priority: Minor > > I am using Maven version 2.0.4 > I am experimenting with Maven to see if it will suit my organizations needs > and I have created a simple example that looks like the following: > App1Pom > + App1Ear > + App1Jar > (pom.xml snippet) > > App1Ear > App1Jar > > When I generate the site using mvn site, the "About" page for App1Pom shows > the two modules in the module section of the navigation, but neither has an > anchor. When I navigate to another section, both module entries will now > contain an anchor that points to index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > (project-info.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > When I generate the site using mvn site:stage, the navigation section > contains the correct entries of App1Ear/index.html and App1Jar/index.html. > (index.html snippet) > Modules > > > > App1Ear > > > > App1Jar > > > I have tried to review the current bug list to see if this problem has > already been reported, but I was not able to see an entry that describes this > situation. If I have a usage problem please point me to some documentation > that can help me understand. > Thanks. > Dale Chapman. -- 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: (MSITE-238) multi project default URL is wrong
[ http://jira.codehaus.org/browse/MSITE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103017 ] John Allen commented on MSITE-238: -- You should not be including any 'target' stuff in URLs - The URLs will resolve properly when the project has been either staged (site:stage) or deployed (site:deploy). Referential addressing never works until the entities in question have been placed in the correct namespace (in this case deployed) > multi project default URL is wrong > -- > > Key: MSITE-238 > URL: http://jira.codehaus.org/browse/MSITE-238 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Paul Sundling >Priority: Trivial > > In multi module projects the default URL if non is included is > //target/site//index.html , but it > should be ///target/site/index.html. -- 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: (MSITE-169) links to modules where not working if a modules dir is used
[ http://jira.codehaus.org/browse/MSITE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103015 ] John Allen commented on MSITE-169: -- By default maven assumes that modules live under the parent project's directory. And Jason is dead right, simply redeclare the correct URL and distroManagement.site.utl info in all the projects to avoid this, in your case, invalid assumption > links to modules where not working if a modules dir is used > --- > > Key: MSITE-169 > URL: http://jira.codehaus.org/browse/MSITE-169 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6 >Reporter: Mathias Brökelmann > Attachments: MNG-MSITE-169-maven-site-plugin.patch > > > I've to place the modules into a separate directory: > root/ > ..pom.xml > ..modules/ > module1 > module2 > this is supported by maven through > > modules/module1 > modules/module2 > > in pom. > but the site generation seems to be broken: > if mvn site-deploy is used the links to the modules contain > modules/module1/index.html which is ok but unfortunately the generated site > structure will be generated as follows: > root/ > ..module1 > ..module2 > The result is that the links do not work. > If I run mvn site-stage everything looks ok. The links doesn't contain > modules dir anymore and eveything is working. -- 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: (MSITE-236) multi module reporting - main page doesn't show links to contained modules
[ http://jira.codehaus.org/browse/MSITE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103014 ] John Allen commented on MSITE-236: -- If you mean modules menu, in the top LHS (using the default site.xml) then yes they should be links and if they're not something else is afoot. Note that those module links should be on every generated page, not just the index.html one. > multi module reporting - main page doesn't show links to contained modules > -- > > Key: MSITE-236 > URL: http://jira.codehaus.org/browse/MSITE-236 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Jan Vissers > > In a multi module project, the "site" generates a main page index.html, which > has the contained modules on the upper left hand corner in bold face. These > should be hyperlinks to the actual module's index.html -- 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: (MSITE-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103013 ] John Allen commented on MSITE-132: -- There are indeed some gotchas re the naming of artifactIds and directories in Maven. for instance the release plugin assumes artifactId == directory name (or at least it used to) and thus most people have those being the same. Note that lets you jump into any directory for a module project but i didnt think that a project's name was ever used in any form of path construction. > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103012 ] John Allen edited comment on MSITE-159 at 7/23/07 12:48 PM: IMHO a project.URL is supposed to point to the web accessible location for that project and thus yes there is tight coupling between the distroManagement.site.url and the project.URL. If one wants to redirect/map via web mechanism the project.URL to some other web location then that's fine too. (i.e. redirect your htdocs requests to htdocs/site) Re isnt that why you define them as absolute? Well yes but also not really, a project's URL is absolute as it is its published external web address accessible from anywhere for that artifact. I can depend on your project and will want to link to its web materials. If you made your sub-modules use explicitly defined relative URLs then they would never be accessible to anyone other than your related site pages (ie parent/children). Re offline - We find it easier to generate our offline docs using these auto-generated relative URLs, we get a sompletely self referential site and the browser doesnt try and jump online all the time. I expect the real answer to these 'i dont like', 'i do like' issues with relative URLs is to make it a configuration option :) was: Re isnt that why you define them as absolute? Well yes but also not really, a project's URL is absolute as it is its published external web address accessible from anywhere. I can depend on your project and will want to link to it and will need this to see your site. If you made your sub-modules use explicitly defined relative URLs then they would never be accessible to anyone other than your related site pages (ie parent/children). We find it easier to generate our offline docs using relatives as well via the site:stage mojo - this lets us create a completely self referential site without having the browser try and jump online all the time. I expect the real answer to these 'i dont like', 'i do like' issues with relative URLs is to make it a configuration option :) > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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
