[jira] Created: (MNG-4931) Guide or tutorial to create a multipage site report
Guide or tutorial to create a multipage site report --- Key: MNG-4931 URL: http://jira.codehaus.org/browse/MNG-4931 Project: Maven 2 & 3 Issue Type: Task Components: Documentation: Guides Reporter: qualitesys The Maven site is nice for simple static HTML doc generation Would be nice to have a tutorial to create a simple Hello World multipage maven report (MavenMultiPageReport). Dispite intense web search, found nothing yet. -- 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: (MEAR-134) no library-directory in application.xml if version is 6
[ http://jira.codehaus.org/browse/MEAR-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-134: - Fix Version/s: 2.4.3 good catch, thanks > no library-directory in application.xml if version is 6 > --- > > Key: MEAR-134 > URL: http://jira.codehaus.org/browse/MEAR-134 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Michael Brackx > Fix For: 2.4.3 > > Attachments: ear-lib-dir.patch > > > There is no library-directory in application.xml if version is 6. > In ApplicationXmlWriter.write() the if around should also check for version 6. > Or to be more future safe, it could check for >= 5 (with a version aware > comparator). -- 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] Work started: (MEAR-134) no library-directory in application.xml if version is 6
[ http://jira.codehaus.org/browse/MEAR-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MEAR-134 started by Stephane Nicoll. > no library-directory in application.xml if version is 6 > --- > > Key: MEAR-134 > URL: http://jira.codehaus.org/browse/MEAR-134 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Michael Brackx >Assignee: Stephane Nicoll > Fix For: 2.4.3 > > Attachments: ear-lib-dir.patch > > > There is no library-directory in application.xml if version is 6. > In ApplicationXmlWriter.write() the if around should also check for version 6. > Or to be more future safe, it could check for >= 5 (with a version aware > comparator). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEAR-134) no library-directory in application.xml if version is 6
[ http://jira.codehaus.org/browse/MEAR-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-134. Resolution: Fixed Applied, thanks. > no library-directory in application.xml if version is 6 > --- > > Key: MEAR-134 > URL: http://jira.codehaus.org/browse/MEAR-134 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Michael Brackx >Assignee: Stephane Nicoll > Fix For: 2.4.3 > > Attachments: ear-lib-dir.patch > > > There is no library-directory in application.xml if version is 6. > In ApplicationXmlWriter.write() the if around should also check for version 6. > Or to be more future safe, it could check for >= 5 (with a version aware > comparator). -- 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: (SUREFIRE-663) Allow custom Junit4 RunListeners to be specified
[ http://jira.codehaus.org/browse/SUREFIRE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247279#action_247279 ] Kristian Rosenvold commented on SUREFIRE-663: - The patch reformats the code in a code-standard that is not ASF. Also an integration test is a requirement. There is a org.apache.maven.surefire.junitcore.DiagnosticRunListener that should be usable to make an IT (it's in the 4.7 provider, you should be able to include that as a dependency within the actual IT) Have a look at for instance surefire-integration-tests/src/test/resources/surefire-408-manual-provider-selection and the accompanying Surefire408ManualProviderSelectionIT.java for a nice starting point. > Allow custom Junit4 RunListeners to be specified > > > Key: SUREFIRE-663 > URL: http://jira.codehaus.org/browse/SUREFIRE-663 > Project: Maven Surefire > Issue Type: New Feature > Components: Junit 4.x support >Affects Versions: 2.6 >Reporter: Matthew Gilliard > Attachments: surefire_junit4_listener.patch > > > It would be nice to allow listing of FQCNs of Junit4 RunListeners in user's > pom.xml so that they can add their own custom RunListeners. Syntax would be > the same as for TestNG, ie: > > > listener > > list,of,FQCNs,implementing,org.junit.runner.notification.RunListener > ... > patch attached for surefire-junit4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-274) unpack mojo suffers from PLXUTILS-64
[
http://jira.codehaus.org/browse/MDEP-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sanchez closed MDEP-274.
---
Resolution: Duplicate
Assignee: Carlos Sanchez (was: Brian Fox)
See MDEP-138
> unpack mojo suffers from PLXUTILS-64
>
>
> Key: MDEP-274
> URL: http://jira.codehaus.org/browse/MDEP-274
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.1
>Reporter: Peter Lynch
>Assignee: Carlos Sanchez
>
> Unpacking a tar.gz file with dependency:unpack I got this
> {noformat}
> org.codehaus.plexus.archiver.ArchiverException: chmod exit code was: 1
> at
> org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:59)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:236)
> at
> org.codehaus.plexus.archiver.tar.TarUnArchiver.execute(TarUnArchiver.java:92)
> {noformat}
> The problem stems from PLXUTILS-64. The dependency on plexus-utils should be
> upgraded to at least
> version 1.5.1 to prevent this problem.
> I tested with this as a plugin dependency and the problem went away.
>
> org.codehaus.plexus
> plexus-utils
> 1.5.15
>
--
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: (SUREFIRE-663) Allow custom Junit4 RunListeners to be specified
[ http://jira.codehaus.org/browse/SUREFIRE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247282#action_247282 ] Kristian Rosenvold commented on SUREFIRE-663: - Actually there is an It for the corresponding testng feature that can be used/expanded. Use search to find it. > Allow custom Junit4 RunListeners to be specified > > > Key: SUREFIRE-663 > URL: http://jira.codehaus.org/browse/SUREFIRE-663 > Project: Maven Surefire > Issue Type: New Feature > Components: Junit 4.x support >Affects Versions: 2.6 >Reporter: Matthew Gilliard > Attachments: surefire_junit4_listener.patch > > > It would be nice to allow listing of FQCNs of Junit4 RunListeners in user's > pom.xml so that they can add their own custom RunListeners. Syntax would be > the same as for TestNG, ie: > > > listener > > list,of,FQCNs,implementing,org.junit.runner.notification.RunListener > ... > patch attached for surefire-junit4 -- 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] Moved: (MNGSITE-123) Guide or tutorial to create a multipage site report
[ http://jira.codehaus.org/browse/MNGSITE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MNG-4931 to MNGSITE-123: Complexity: (was: Intermediate) Component/s: (was: Documentation: Guides) Key: MNGSITE-123 (was: MNG-4931) Project: Maven Project Web Site (was: Maven 2 & 3) > Guide or tutorial to create a multipage site report > --- > > Key: MNGSITE-123 > URL: http://jira.codehaus.org/browse/MNGSITE-123 > Project: Maven Project Web Site > Issue Type: Task >Reporter: qualitesys > > The Maven site is nice for simple static HTML doc generation > Would be nice to have a tutorial to create a simple Hello World multipage > maven report (MavenMultiPageReport). Dispite intense web search, found > nothing yet. -- 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: (MPIR-210) Project Summary Download link points to distributionManagement (upload) url
Project Summary Download link points to distributionManagement (upload) url --- Key: MPIR-210 URL: http://jira.codehaus.org/browse/MPIR-210 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: summary Affects Versions: 2.3 Reporter: Lukas Theussl This was introduced in MPIR-128. If no downloadUrl is given in the pom, a link to distributionManagement.repository.url is generated. According to the pom reference, distributionManagement specifies where (and how) a project will get to a remote repository when it is deployed. When no downloadUrl is specified, no Download section should be generated IMO. -- 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-458) Fixing the order of items in "Modules" menu
[
http://jira.codehaus.org/browse/MSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247291#action_247291
]
Dennis Lundberg commented on MSITE-458:
---
OK thanks.
A sample project would be much appreciated.
> Fixing the order of items in "Modules" menu
> ---
>
> Key: MSITE-458
> URL: http://jira.codehaus.org/browse/MSITE-458
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: New Feature
> Components: multi module
>Affects Versions: 2.1
>Reporter: Andreas Sewe
>
> Currently, it is impossible to influence the order in which the "Modules"
> show up in a generated site's menu when including them like this in the site
> descriptor:
> bq.
> As far as I can tell, the order of items in the menu depends on the order in
> which Maven builds the modules -- and this does not always put the most
> important module at the top of the list. In fact, the top of the list is in
> all likelihood occupied by various low-level infrastructure modules; the
> high-level, user-visible modules typically come much later. :-(
> This also means that the order of menu items depends on the module's
> dependencies; thus, this can result in unforeseen changes to the *site* when
> one module's *build* changes. Why doesn't Maven simply use the order of the
> {{module}} elements? That would be simple and predictable.
--
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: (SCM-587) Branch support for Mercurial (hg) SCM provider
Branch support for Mercurial (hg) SCM provider -- Key: SCM-587 URL: http://jira.codehaus.org/browse/SCM-587 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-mercurial (hg) Affects Versions: 1.5 Reporter: Henning Schmiedehausen Attachments: hg-branch-support.patch The patch adds branch support to the hg (Mercurial) SCM provider. -- 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-627) Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories
Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories --- Key: MRELEASE-627 URL: http://jira.codehaus.org/browse/MRELEASE-627 Project: Maven 2.x Release Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Henning Schmiedehausen Attachments: release-plugin-patch The maven-release-plugin is pretty much designed to work with a single repository and tag and branch from this. As soon as a project tree is more complex and e.g. uses nested or multiple repositories (such as the Mercurial subrepos), it fails. The attached patch fixes most of the use cases that allow releasing large (reactor) projects that span multiple projects and use one repository per project. New properties: revertOrder (boolean) - Default: false Reverts the order in which commit, tag and branch process multi-repos. E.g. in Mercurial, the main repository (which contains the subrepos) must be processed last, because it implicitly records state of the relationship between the main and the sub repository. If it gets committed first, then this state is not recorded correctly. By reverting the order, the main repository is committed last. commitAllChanges (boolean) - Default: false The release plugin tries to explicitly list which files it commits. However, in the case of a multi-repository tree, in then tries e.g. to commit repo/pom.xml, repo/a/pom.xml and repo/b/pom.xml in the context of "repo" which then fails (because repo/a/pom.xml and repo/b/pom.xml are actually part of the subrepos a and b). Setting this parameters omits the list of files and tells the SCM to "commit everything". E.g. Mercurial then picks up the changes correctly and also records the implicit state between master and sub repositories correctly. tagByProject, branchByProject (boolean) - Default: false Similar to the existing 'commitByProject', these options select whether a tag or a branch should be created by running the tag command in the root of the tree or by looping through all projects and tagging or branching them one-by-one. Default is to tag in the root. tagRequiresCommit / branchRequiresCommit (boolean) - Default: false Mercurial manages tags by adding entries to the '.hgtags' file, which is managed implicitly by the SCM. If a subrepository gets tagged as part of a larger, multi-repo project, then the changes must be explicitly committed, else they don't get picked up by the main repository. This sounds more complicated than it actually is, the summary is that "this must be 'true' for Mercurial and probably "false" for everything else. Those changes *should* work with the 1.4 SCM provider, but were tested only with the 1.5-SNAPSHOT release. It also benefits from fixing the pushChanges support in the Mercurial provider. If you want to test drive this patch, you should also be interested in SCM-587. -- 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-627) Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories
[
http://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247308#action_247308
]
Henning Schmiedehausen edited comment on MRELEASE-627 at 12/11/10 10:09 PM:
In case, you are desperate, those are the settings to successfully run
"release:prepare and release:perform (and release:branch and release:stage) on
a Mercurial subrepo tree where the main repository also contains the project
POM and each project is a subrepo (which should be the most common layout):
{code}
org.apache.maven.plugins
maven-release-plugin
2.2-SNAPSHOT
org.apache.maven.scm
maven-scm-api
1.5-SNAPSHOT
org.apache.maven.scm
maven-scm-provider-hg
1.5-SNAPSHOT
true
true
false
true
true
true
true
false
{code}
Settings for other systems (e.g. git or bzr) should be similar, depending on
whether committing the main repo also touches the sub-repos or not.
was (Author: hgschmie):
In case, you are desperate, those are the settings to successfully run
"release:prepare and release:perform (and release:branch and release:stage) on
a Mercurial subrepo tree where the main repository also contains the project
POM and each project is a subrepo (which should be the most common layout):
org.apache.maven.plugins
maven-release-plugin
2.2-SNAPSHOT
org.apache.maven.scm
maven-scm-api
1.5-SNAPSHOT
org.apache.maven.scm
maven-scm-provider-hg
1.5-SNAPSHOT
true
true
false
true
true
true
true
false
Settings for other systems (e.g. git or bzr) should be similar, depending on
whether committing the main repo also touches the sub-repos or not.
> Fix multi-repository support in the release plugin and make it work with e.g.
> mercurial subrepositories
> ---
>
> Key: MRELEASE-627
> URL: http://jira.codehaus.org/browse/MRELEASE-627
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Henning Schmiedehausen
> Attachments: release-plugin-patch
>
>
> The maven-release-plugin is pretty much designed to work with a single
> repository and tag and branch from this. As soon as a project tree is more
> complex and e.g. uses nested or multiple repositories (such as the Mercurial
> subrepos), it fails.
> The attached patch fixes most of the use cases that allow releasing large
> (reactor) projects that span multiple projects and use one repository per
> project.
> New properties:
> revertOrder (boolean) - Default: false
> Reverts the order in which commit, tag and branch process multi-repos. E.g.
> in Mercurial, the main repository (which contains the subrepos) must be
> processed last, because it implicitly records state of the relationship
> between the main and the sub repository. If it gets committed first, then
> this state is not recorded correctly. By reverting the order, the main
> repository is committed last.
> commitAllChanges (boolean) - Default: false
> The release plugin tries to explicitly list which files it commits. However,
> in the case of a multi-repository tree, in then tries e.g. to commit
> repo/pom.xml, repo/a/pom.xml and repo/b/pom.xml in the context of "repo"
> which then fails (because repo/a/pom.xml and repo/b/pom.xml are actually part
> of the subrepos a and b). Setting this parameters omits the li
[jira] Commented: (MRELEASE-627) Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories
[ http://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247308#action_247308 ] Henning Schmiedehausen commented on MRELEASE-627: - In case, you are desperate, those are the settings to successfully run "release:prepare and release:perform (and release:branch and release:stage) on a Mercurial subrepo tree where the main repository also contains the project POM and each project is a subrepo (which should be the most common layout): org.apache.maven.plugins maven-release-plugin 2.2-SNAPSHOT org.apache.maven.scm maven-scm-api 1.5-SNAPSHOT org.apache.maven.scm maven-scm-provider-hg 1.5-SNAPSHOT true true false true true true true false Settings for other systems (e.g. git or bzr) should be similar, depending on whether committing the main repo also touches the sub-repos or not. > Fix multi-repository support in the release plugin and make it work with e.g. > mercurial subrepositories > --- > > Key: MRELEASE-627 > URL: http://jira.codehaus.org/browse/MRELEASE-627 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Henning Schmiedehausen > Attachments: release-plugin-patch > > > The maven-release-plugin is pretty much designed to work with a single > repository and tag and branch from this. As soon as a project tree is more > complex and e.g. uses nested or multiple repositories (such as the Mercurial > subrepos), it fails. > The attached patch fixes most of the use cases that allow releasing large > (reactor) projects that span multiple projects and use one repository per > project. > New properties: > revertOrder (boolean) - Default: false > Reverts the order in which commit, tag and branch process multi-repos. E.g. > in Mercurial, the main repository (which contains the subrepos) must be > processed last, because it implicitly records state of the relationship > between the main and the sub repository. If it gets committed first, then > this state is not recorded correctly. By reverting the order, the main > repository is committed last. > commitAllChanges (boolean) - Default: false > The release plugin tries to explicitly list which files it commits. However, > in the case of a multi-repository tree, in then tries e.g. to commit > repo/pom.xml, repo/a/pom.xml and repo/b/pom.xml in the context of "repo" > which then fails (because repo/a/pom.xml and repo/b/pom.xml are actually part > of the subrepos a and b). Setting this parameters omits the list of files and > tells the SCM to "commit everything". E.g. Mercurial then picks up the > changes correctly and also records the implicit state between master and sub > repositories correctly. > tagByProject, branchByProject (boolean) - Default: false > Similar to the existing 'commitByProject', these options select whether a tag > or a branch should be created by running the tag command in the root of the > tree or by looping through all projects and tagging or branching them > one-by-one. Default is to tag in the root. > tagRequiresCommit / branchRequiresCommit (boolean) - Default: false > Mercurial manages tags by adding entries to the '.hgtags' file, which is > managed implicitly by the SCM. If a subrepository gets tagged as part of a > larger, multi-repo project, then the changes must be explicitly committed, > else they don't get picked up by the main repository. This sounds more > complicated than it actually is, the summary is that "this must be 'true' for > Mercurial and probably "false" for everything else. > Those changes *should* work with the 1.4 SCM provider, but were tested only > with the 1.5-SNAPSHOT release. It also benefits from fixing the pushChanges > support in the Mercurial provider. > If you want to test drive this patch, you should also be interested in > SCM-587. -- 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
