[jira] Created: (MDOCCK-11) Add support for Velocity filtered documents
Add support for Velocity filtered documents --- Key: MDOCCK-11 URL: http://jira.codehaus.org/browse/MDOCCK-11 Project: Maven 2.x Documentation Checker Plugin Issue Type: Improvement Affects Versions: 1.0-beta-2 Reporter: Dennis Lundberg Since version 2.0-beta-6 the site plugin supports Velocity filtered documents by adding .vm to the document file name. The DOCCK plugin should support these documents when checking for document 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] Reopened: (MCHECKSTYLE-86) Lock down encoding used to read source files
[ http://jira.codehaus.org/browse/MCHECKSTYLE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann reopened MCHECKSTYLE-86: -- Needs to be reverted according to [user poll|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-to16958386.html#a16958386]. > Lock down encoding used to read source files > > > Key: MCHECKSTYLE-86 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-86 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Benjamin Bentmann >Assignee: Dennis Lundberg >Priority: Minor > Fix For: 2.2 > > Attachments: fixed-charset.patch > > > Since [version > 3.5|http://checkstyle.sourceforge.net/releasenotes.html#Release%203.5], > Checkstyle allows to configure the encoding used to read source files > (somehow weird, they included this setting in the XML config which limits > reusability among unrelated projects). Unless this is specified by the user > via the [charset > property|http://checkstyle.sourceforge.net/config.html#TreeWalker], it > defaults to the system property "file.encoding". This makes the checks > platform-dependent and possibly fail. For reproducible builds, the encoding > should be locked down. -- 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: (MCHECKSTYLE-94) Don't fail build if config file not reachable
Don't fail build if config file not reachable
-
Key: MCHECKSTYLE-94
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-94
Project: Maven 2.x Checkstyle Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Benjamin Bentmann
Over at Mojo we use the {{maven_checks}} from the SVN trunk. Trying to build
the site fails if the SVN server is down causes:
{noformat}
[INFO] Generating "Checkstyle" report.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error during page generation
Embedded error: Error rendering Maven report: Unable to find configuration file
location.
Connection timed out: connect
{noformat}
The {{checkstyle:check}} goal should abort the build for sure, but the mere
report generation by {{checkstyle:checkstyle} should simply output a warning
and continue with the show.
--
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: (MCHECKSTYLE-94) Don't fail site generation if config file not reachable
[
http://jira.codehaus.org/browse/MCHECKSTYLE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MCHECKSTYLE-94:
-
Summary: Don't fail site generation if config file not reachable (was:
Don't fail build if config file not reachable)
> Don't fail site generation if config file not reachable
> ---
>
> Key: MCHECKSTYLE-94
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-94
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Benjamin Bentmann
>
> Over at Mojo we use the {{maven_checks}} from the SVN trunk. Trying to build
> the site fails if the SVN server is down causes:
> {noformat}
> [INFO] Generating "Checkstyle" report.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: Unable to find configuration
> file location.
> Connection timed out: connect
> {noformat}
> The {{checkstyle:check}} goal should abort the build for sure, but the mere
> report generation by {{checkstyle:checkstyle} should simply output a warning
> and continue with the show.
--
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-3571) Allow use of ! when deactivating profiles
[
http://jira.codehaus.org/browse/MNG-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135299#action_135299
]
Paul Benedict commented on MNG-3571:
Was there also a commit to update any documentation using the
exclamation/plus/minus syntax?
> Allow use of ! when deactivating profiles
> -
>
> Key: MNG-3571
> URL: http://jira.codehaus.org/browse/MNG-3571
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
>
> The current syntax for deactivating a profile from the command line is:
> {{mvn -P-myProfile}}
> It would be more intuitive if the exclamation point could be used in addition
> to the dash.
> {{mvn -P!myProfile}}
--
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: (MDOCCK-10) Use proper file encoding when checking site descriptor
[
http://jira.codehaus.org/browse/MDOCCK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135298#action_135298
]
Dennis Lundberg commented on MDOCCK-10:
---
I've implemented a fix for this by replacing the above code with the following:
{code:java}
String siteHtml = IOUtil.toString( ReaderFactory.newXmlReader( siteXml ) );
{code}
and added a dependency on plexus-utils-1.4.5 and bumped the Maven prerequisite
to 2.0.6.
Is that enough to fix this issue?
> Use proper file encoding when checking site descriptor
> --
>
> Key: MDOCCK-10
> URL: http://jira.codehaus.org/browse/MDOCCK-10
> Project: Maven 2.x Documentation Checker Plugin
> Issue Type: Bug
>Affects Versions: 1.0-beta-2
>Reporter: Benjamin Bentmann
>
> This is not working reliably:
> {code:java}
> String siteHtml = FileUtils.fileRead(
> siteXml.getAbsolutePath() );
> {code}
> See also [Common
> Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html#a15919795].
--
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: (MDOCCK-11) Add support for Velocity filtered documents
[ http://jira.codehaus.org/browse/MDOCCK-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MDOCCK-11. - Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 1.0-beta-3 > Add support for Velocity filtered documents > --- > > Key: MDOCCK-11 > URL: http://jira.codehaus.org/browse/MDOCCK-11 > Project: Maven 2.x Documentation Checker Plugin > Issue Type: Improvement >Affects Versions: 1.0-beta-2 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 1.0-beta-3 > > > Since version 2.0-beta-6 the site plugin supports Velocity filtered documents > by adding .vm to the document file name. The DOCCK plugin should support > these documents when checking for document 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: (MDOCCK-10) Use proper file encoding when checking site descriptor
[
http://jira.codehaus.org/browse/MDOCCK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135300#action_135300
]
Benjamin Bentmann commented on MDOCCK-10:
-
Yepp, that should be fine. You could however consider to close the reader
afterwards.
> Use proper file encoding when checking site descriptor
> --
>
> Key: MDOCCK-10
> URL: http://jira.codehaus.org/browse/MDOCCK-10
> Project: Maven 2.x Documentation Checker Plugin
> Issue Type: Bug
>Affects Versions: 1.0-beta-2
>Reporter: Benjamin Bentmann
>
> This is not working reliably:
> {code:java}
> String siteHtml = FileUtils.fileRead(
> siteXml.getAbsolutePath() );
> {code}
> See also [Common
> Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html#a15919795].
--
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: (MCHECKSTYLE-86) Lock down encoding used to read source files
[ http://jira.codehaus.org/browse/MCHECKSTYLE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-86. -- Resolution: Won't Fix Fix Version/s: (was: 2.2) > Lock down encoding used to read source files > > > Key: MCHECKSTYLE-86 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-86 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Benjamin Bentmann >Assignee: Dennis Lundberg >Priority: Minor > Attachments: fixed-charset.patch > > > Since [version > 3.5|http://checkstyle.sourceforge.net/releasenotes.html#Release%203.5], > Checkstyle allows to configure the encoding used to read source files > (somehow weird, they included this setting in the XML config which limits > reusability among unrelated projects). Unless this is specified by the user > via the [charset > property|http://checkstyle.sourceforge.net/config.html#TreeWalker], it > defaults to the system property "file.encoding". This makes the checks > platform-dependent and possibly fail. For reproducible builds, the encoding > should be locked down. -- 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-3582) Support 'parameter' mechanism for mojo aggregated objects
Support 'parameter' mechanism for mojo aggregated objects
-
Key: MNG-3582
URL: http://jira.codehaus.org/browse/MNG-3582
Project: Maven 2
Issue Type: Improvement
Components: Plugin Requests
Affects Versions: 2.0.8
Reporter: Ittay Dror
if class AMojo has a field AObject, then this field can have xdoclet tags to
define how to instantiate it (expression, default-value). however, inside the
object, we cannot use this mechanism. so if in AObject, I want a field whose
default value will be ${project.build.finalName}, i have to do get it "manually"
--
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: (MPLUGIN-115) Limit detail help output to a single goal
Limit detail help output to a single goal - Key: MPLUGIN-115 URL: http://jira.codehaus.org/browse/MPLUGIN-115 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: API, Plugin Plugin Affects Versions: 2.4 Reporter: Benjamin Bentmann For plugins with many goals/parameters and thorough documentation, executing "mvn foo:help -Ddetail" will make one drown in output. We should add some parameter to limit the output to a specific goal, e.g. "mvn foo:help -Ddetail -Dgoal=bar" -- 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: (MPLUGIN-115) Limit detail help output to a single goal
[ http://jira.codehaus.org/browse/MPLUGIN-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPLUGIN-115. - Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.4.2 Done in [r657555|http://svn.apache.org/viewvc?view=rev&revision=657555]. > Limit detail help output to a single goal > - > > Key: MPLUGIN-115 > URL: http://jira.codehaus.org/browse/MPLUGIN-115 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement > Components: API, Plugin Plugin >Affects Versions: 2.4 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > Fix For: 2.4.2 > > > For plugins with many goals/parameters and thorough documentation, executing > "mvn foo:help -Ddetail" will make one drown in output. We should add some > parameter to limit the output to a specific goal, e.g. "mvn foo:help -Ddetail > -Dgoal=bar" -- 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: (MNG-3010) Problem parsing version ranges
[ http://jira.codehaus.org/browse/MNG-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-3010: --- Assignee: Herve Boutemy Affects Version/s: 2.0.7 2.0.8 2.0.9 Fix Version/s: 2.1 default version comparison has been improved in artifact 3.0-SNAPSHOT [r656775|http://svn.apache.org/viewvc?view=rev&revision=656775] (15/5/2008). > Problem parsing version ranges > -- > > Key: MNG-3010 > URL: http://jira.codehaus.org/browse/MNG-3010 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, POM >Affects Versions: 2.0.6, 2.0.7, 2.0.8, 2.0.9 > Environment: Linux FC6/ jdk 1.6.0 >Reporter: Gabriele Contini >Assignee: Herve Boutemy > Fix For: 2.1 > > > My pom includes the following dependency: > > > it.unimaticaspa.unique > unilet-core > [5.0.9.0,5.0.10.0) > jar > > When i try to build the project i get the following stacktrace: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Unable to parse version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Unable to parse > version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: > org.apache.maven.project.artifact.InvalidDependencyVersionException: Unable > to parse version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > at > org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:331) > at > org.apache.maven.project.MavenProject.createArtifacts(MavenProject.java:1558) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1236) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: > org.apache.maven.artifact.versioning.InvalidVersionSpecificationException: > Range defies version ordering: [5.0.9.0,5.0.10.0) > at > org.apache.maven.artifact.versioning.VersionRange.parseRestriction(VersionRange.java:210) > at > org.apache.maven.artifact.versioning.VersionRange.createFromVersionSpec(VersionRange.java:125) > at > org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:327) > ... 20 more > It seems that versions are compared as strings, because the problem only > comes out comparing versions with different numbers of digits (such as > 5.0.9.0 and 5.0.10.0). While comparing 5.0.8.0 with 5.0.9.0 everything is > fine
[jira] Reopened: (MNG-3010) Problem parsing version ranges
[ http://jira.codehaus.org/browse/MNG-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy reopened MNG-3010: > Problem parsing version ranges > -- > > Key: MNG-3010 > URL: http://jira.codehaus.org/browse/MNG-3010 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, POM >Affects Versions: 2.0.6, 2.0.7, 2.0.8, 2.0.9 > Environment: Linux FC6/ jdk 1.6.0 >Reporter: Gabriele Contini >Assignee: Herve Boutemy > Fix For: 2.1 > > > My pom includes the following dependency: > > > it.unimaticaspa.unique > unilet-core > [5.0.9.0,5.0.10.0) > jar > > When i try to build the project i get the following stacktrace: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Unable to parse version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Unable to parse > version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: > org.apache.maven.project.artifact.InvalidDependencyVersionException: Unable > to parse version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > at > org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:331) > at > org.apache.maven.project.MavenProject.createArtifacts(MavenProject.java:1558) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1236) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: > org.apache.maven.artifact.versioning.InvalidVersionSpecificationException: > Range defies version ordering: [5.0.9.0,5.0.10.0) > at > org.apache.maven.artifact.versioning.VersionRange.parseRestriction(VersionRange.java:210) > at > org.apache.maven.artifact.versioning.VersionRange.createFromVersionSpec(VersionRange.java:125) > at > org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:327) > ... 20 more > It seems that versions are compared as strings, because the problem only > comes out comparing versions with different numbers of digits (such as > 5.0.9.0 and 5.0.10.0). While comparing 5.0.8.0 with 5.0.9.0 everything is > fine. -- 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: (MNG-3010) Problem parsing version ranges
[ http://jira.codehaus.org/browse/MNG-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-3010. -- Resolution: Fixed > Problem parsing version ranges > -- > > Key: MNG-3010 > URL: http://jira.codehaus.org/browse/MNG-3010 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, POM >Affects Versions: 2.0.6, 2.0.7, 2.0.8, 2.0.9 > Environment: Linux FC6/ jdk 1.6.0 >Reporter: Gabriele Contini >Assignee: Herve Boutemy > Fix For: 2.1 > > > My pom includes the following dependency: > > > it.unimaticaspa.unique > unilet-core > [5.0.9.0,5.0.10.0) > jar > > When i try to build the project i get the following stacktrace: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Unable to parse version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Unable to parse > version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > 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:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: > org.apache.maven.project.artifact.InvalidDependencyVersionException: Unable > to parse version '[5.0.9.0,5.0.10.0)' for dependency > 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: > [5.0.9.0,5.0.10.0) > at > org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:331) > at > org.apache.maven.project.MavenProject.createArtifacts(MavenProject.java:1558) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1236) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: > org.apache.maven.artifact.versioning.InvalidVersionSpecificationException: > Range defies version ordering: [5.0.9.0,5.0.10.0) > at > org.apache.maven.artifact.versioning.VersionRange.parseRestriction(VersionRange.java:210) > at > org.apache.maven.artifact.versioning.VersionRange.createFromVersionSpec(VersionRange.java:125) > at > org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:327) > ... 20 more > It seems that versions are compared as strings, because the problem only > comes out comparing versions with different numbers of digits (such as > 5.0.9.0 and 5.0.10.0). While comparing 5.0.8.0 with 5.0.9.0 everything is > fine. -- 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: (MPLUGIN-114) PluginXdocGenerator NullPointerException
[ http://jira.codehaus.org/browse/MPLUGIN-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPLUGIN-114. - Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.4.2 Fixed in [r657562|http://svn.apache.org/viewvc?view=rev&revision=657562]. The crap with the null collection goes deep down to Plexus which can only be updated in combination with the Maven core... Thanks for the POM, that helped a lot. However, there seems to be something else wrong: Now you end up with an empty goal documentation for the Findbugs Plugin. If this is not a problem on the Groovy side, please fill in another ticket. > PluginXdocGenerator NullPointerException > > > Key: MPLUGIN-114 > URL: http://jira.codehaus.org/browse/MPLUGIN-114 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API >Affects Versions: 2.3 >Reporter: Garvin LeClaire >Assignee: Benjamin Bentmann > Fix For: 2.4.2 > > Attachments: pom.xml > > > When creating a site I get the following stack trace: > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 33 seconds > [INFO] Finished at: Wed May 14 23:36:51 EDT 2008 > [INFO] Final Memory: 41M/63M > I have tried and get the same results with version of the site plg-in back to > 2.0-beta-3 > Any suggestions?? -- 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: (MPLUGIN-116) Improve XHTML compliance
Improve XHTML compliance
Key: MPLUGIN-116
URL: http://jira.codehaus.org/browse/MPLUGIN-116
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Components: API, Plugin Plugin
Affects Versions: 2.4
Reporter: Benjamin Bentmann
Priority: Trivial
The javadoc snippet
{noformat}
This is the coolest mojo ever, really!
{noformat}
from a mojo/parameter description is transformed into
{noformat}
This is the coolest mojo ever, really!
{noformat}
by the {{PluginXdocGenerator}} which is not valid XHTML.
--
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: (MPLUGIN-116) Improve XHTML compliance
[
http://jira.codehaus.org/browse/MPLUGIN-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPLUGIN-116.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.4.2
Fixed in [r657566|http://svn.apache.org/viewvc?view=rev&revision=657566].
> Improve XHTML compliance
>
>
> Key: MPLUGIN-116
> URL: http://jira.codehaus.org/browse/MPLUGIN-116
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Components: API, Plugin Plugin
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Trivial
> Fix For: 2.4.2
>
>
> The javadoc snippet
> {noformat}
> This is the coolest mojo ever, really!
> {noformat}
> from a mojo/parameter description is transformed into
> {noformat}
>
> This is the coolest mojo ever, really!
>
> {noformat}
> by the {{PluginXdocGenerator}} which is not valid XHTML.
--
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: (MPLUGIN-117) Emphasize goal/parameter deprecation
Emphasize goal/parameter deprecation Key: MPLUGIN-117 URL: http://jira.codehaus.org/browse/MPLUGIN-117 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: API, Plugin Plugin Affects Versions: 2.4 Reporter: Benjamin Bentmann Priority: Minor Currently, the deprecation info is printed in the attribute/detail list of a goal or parameter, respectively. It is easily overlooked in this way. -- 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: (MPLUGIN-117) Emphasize goal/parameter deprecation
[ http://jira.codehaus.org/browse/MPLUGIN-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPLUGIN-117. - Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.4.2 Done in [r657607|http://svn.apache.org/viewvc?view=rev&revision=657607]. > Emphasize goal/parameter deprecation > > > Key: MPLUGIN-117 > URL: http://jira.codehaus.org/browse/MPLUGIN-117 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement > Components: API, Plugin Plugin >Affects Versions: 2.4 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Minor > Fix For: 2.4.2 > > > Currently, the deprecation info is printed in the attribute/detail list of a > goal or parameter, respectively. It is easily overlooked in this way. -- 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-3583) Shorten the path to the IT for MNG-3341
Shorten the path to the IT for MNG-3341
---
Key: MNG-3583
URL: http://jira.codehaus.org/browse/MNG-3583
Project: Maven 2
Issue Type: Task
Components: integration tests
Environment: Windows XP
Reporter: Dennis Lundberg
Some paths in that IT are to long for a Windows file system. Checking out
core-integration-testing to a folder with the same name in the root of a
Windows drive doesn't work because the length of the path exceeds the 255
character limit.
{noformat}
svn: Can't open file
'core-integration-tests\src\test\resources\mng-3341-metadataUpdatedFromDeploymentRepository\deployment-repository\org\apache\maven\its\mng3341\test-artifact\1.0-SNAPSHOT\.svn\tmp\text-base\test-artifact-1.0-20080306.011328-1.pom.md5.svn-base'
{noformat}
Please make the path shorter.
--
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: (MJAVADOC-185) Revert MJAVADOC-165 and default to platform encoding
[ http://jira.codehaus.org/browse/MJAVADOC-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MJAVADOC-185. -- Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: 2.5 done in r657619 > Revert MJAVADOC-165 and default to platform encoding > - > > Key: MJAVADOC-185 > URL: http://jira.codehaus.org/browse/MJAVADOC-185 > Project: Maven 2.x Javadoc Plugin > Issue Type: Wish >Affects Versions: 2.4 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.5 > > > According to the [user poll about the default file > encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], > this should be the platform default encoding which suggests to revert the > changes made for MJAVADOC-165. Since that would be a breaking change it is > left to users to vote for this issue if they feelt it's worth to have it back. -- 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: (JXR-62) Make file encoding default to platform encoding
[ http://jira.codehaus.org/browse/JXR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed JXR-62. Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: 2.2 done in [r657630|http://svn.apache.org/viewvc?view=rev&revision=657630] for trunk and [r657631|http://svn.apache.org/viewvc?view=rev&revision=657631] for sandbox > Make file encoding default to platform encoding > --- > > Key: JXR-62 > URL: http://jira.codehaus.org/browse/JXR-62 > Project: Maven JXR > Issue Type: Wish > Components: maven2 jxr plugin >Affects Versions: 2.0 >Reporter: Benjamin Bentmann >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.2 > > > According to the [user poll about the default file > encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], > the inputEncoding and outputEncoding should default to the platform default > encoding instead of Latin-1. Since that would be a breaking change it is left > to users to vote for this issue if they feelt it's worth to have it like that. > If the change is made, we should have the plugin output a warning when using > the platform encoding. -- 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: (MSITE-326) Make file encoding default to platform encoding
Make file encoding default to platform encoding --- Key: MSITE-326 URL: http://jira.codehaus.org/browse/MSITE-326 Project: Maven 2.x Site Plugin Issue Type: Wish Components: encoding Affects Versions: 2.0-beta-6, 2.0-beta-5 Reporter: Herve Boutemy According to the user poll about the default file encoding, the inputEncoding and outputEncoding should default to the platform default encoding instead of Latin-1. Since that would be a breaking change it is left to users to vote for this issue if they feelt it's worth to have it like that. If the change is made, we should have the plugin output a warning when using the platform encoding. -- 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: (MSITE-326) Make file encoding default to platform encoding
[ http://jira.codehaus.org/browse/MSITE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSITE-326: Fix Version/s: 2.0-beta-7 > Make file encoding default to platform encoding > --- > > Key: MSITE-326 > URL: http://jira.codehaus.org/browse/MSITE-326 > Project: Maven 2.x Site Plugin > Issue Type: Wish > Components: encoding >Affects Versions: 2.0-beta-5, 2.0-beta-6 >Reporter: Herve Boutemy > Fix For: 2.0-beta-7 > > > According to the user poll about the default file encoding, the inputEncoding > and outputEncoding should default to the platform default encoding instead of > Latin-1. Since that would be a breaking change it is left to users to vote > for this issue if they feelt it's worth to have it like that. > If the change is made, we should have the plugin output a warning when using > the platform encoding. -- 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: (MSITE-326) Make file encoding default to platform encoding
[ http://jira.codehaus.org/browse/MSITE-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MSITE-326: Description: According to the [user poll about the default file encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], the inputEncoding and outputEncoding should default to the platform default encoding instead of Latin-1. Since that would be a breaking change it is left to users to vote for this issue if they feelt it's worth to have it like that. If the change is made, we should have the plugin output a warning when using the platform encoding. was: According to the user poll about the default file encoding, the inputEncoding and outputEncoding should default to the platform default encoding instead of Latin-1. Since that would be a breaking change it is left to users to vote for this issue if they feelt it's worth to have it like that. If the change is made, we should have the plugin output a warning when using the platform encoding. > Make file encoding default to platform encoding > --- > > Key: MSITE-326 > URL: http://jira.codehaus.org/browse/MSITE-326 > Project: Maven 2.x Site Plugin > Issue Type: Wish > Components: encoding >Affects Versions: 2.0-beta-5, 2.0-beta-6 >Reporter: Herve Boutemy > Fix For: 2.0-beta-7 > > > According to the [user poll about the default file > encoding|http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-td16958386.html], > the inputEncoding and outputEncoding should default to the platform default > encoding instead of Latin-1. Since that would be a breaking change it is left > to users to vote for this issue if they feelt it's worth to have it like that. > If the change is made, we should have the plugin output a warning when using > the platform encoding. -- 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: (SCM-258) The perforce provider should be able to accept complex filespecs using a clientspec rather than the path in the SCM url
[ http://jira.codehaus.org/browse/SCM-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135325#action_135325 ] Harold Shinsato commented on SCM-258: - Is there any way to make the perforce plugin work with the release plugin if you don't have a one directory clientspec? I'm quite confused. The release:prepare task seems to be blocked but it's unclear if this is the issue - but it looks like it might be because of the message that "+//myspec" doesn't match "//myspec", the release:prepare task reports. [INFO] The SCM location in your pom.xml (//myspec) is not equal to the depot location (+//myspec). This happens frequently with branches. Ignoring the SCM location. > The perforce provider should be able to accept complex filespecs using a > clientspec rather than the path in the SCM url > --- > > Key: SCM-258 > URL: http://jira.codehaus.org/browse/SCM-258 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-perforce > Environment: All OS, Maven 2.x using the SCM plugin to talk to > perforce >Reporter: Dana Lacoste > Fix For: future > > > One of the strengths of perforce is the ability to do fairly complex actions > with the clientspec. > For example: > 1 - Checkout two file structures into one location: > //depot1/tree1/... //client/project/tree1 > //depot2/tree2/... //client/project/tree2 > 2 - Rename file structures at checkout time : > //depot/tree/sample-configuration.xml //client/tree/configuration.xml > The SCM URL format doesn't allow this (and implementing it would be difficult) > Currently, the perforce provider doesn't seem to allow a way to use an > existing clientspec (all codepaths seem to create a new clientspec based on > the URL) > If the provider could allow an existing clientspec to define the file > structure, this functionality could be enabled. > Testing: > I don't have any JUnit experience, but I think this could be tested by: > 1 - Create a clientspec that defines some complex content, for example: > //depot/project/src/... //clientspec/project/src/... > //ThirdParty/... //clientspec/project/ThirdParty/... > 2 - run "mvn scm:checkout" and all files should be checked out. > Implementation Ideas: > I can see multiple ways of doing this, depending on the > restrictions/conventions required > A - Use the existing "bootstrap/target/checkout" dynamic directory structure > - Using "p4 client -o" with the given/predefined/assumed clientspec, > alter the p4_root (the line containing "Root:") and do a "p4 sync -f" >(Definition of the clientspec ideas defined separately below) > B - Assume the clientspec has a defined "Root:" and use that for the purposes > of "locating" files (needed for tag/editing/checkin purposes) > - As I'm only checking out, I really don't know how this would affect a > checkin :) > C - Separate from above, how to define which clientspec to use: > - In the SCM URL, perhaps with scm:perforce:[EMAIL > PROTECTED]:port:@clientspec_name > (the second @ being a placeholder for a delimiter) > - As an environment variable (perhaps the existing > maven.scm.perforce.clientspec.name, > enabling this functionality (re-use vs. re-create) with a different > property > - Defined in the settings.xml or in the pom.xml in the SCM configuration > properties > I'm sure more details will be required, this is only what I've identified > within my particular situation. -- 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-273) Regression: NullPointerException at end of standalone "release:perform"
[
http://jira.codehaus.org/browse/MRELEASE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135331#action_135331
]
Harold Shinsato commented on MRELEASE-273:
--
I'm seeing this as well. I also executed it in a directory without a pom.
> Regression: NullPointerException at end of standalone "release:perform"
> ---
>
> Key: MRELEASE-273
> URL: http://jira.codehaus.org/browse/MRELEASE-273
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
> Environment: Maven 2.0.7, maven-release-plugin 2.0-alpha-6
>Reporter: Max Bowsher
>Priority: Blocker
> Attachments: release.bug
>
>
> I executed "mvn release:perform -DconnectionUrl=scm:svn:..". The actual
> performing succeeded, but then the plugin failed with a NullPointerException
> - it seems that the plugin attempts to unconditionally run code analogous to
> "mvn release:clean", but this is inappropriate because release:perform is not
> supposed to require a project to be able to run.
> Output:
> {noformat}
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 28 seconds
> [INFO] Finished at: Thu Aug 02 12:53:49 BST 2007
> [INFO] Final Memory: 13M/23M
> [INFO]
>
> [INFO] Cleaning up after release...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [DEBUG] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.shared.release.util.ReleaseUtil.getReleasePom(ReleaseUtil.java:73)
> at
> org.apache.maven.shared.release.util.ReleaseUtil.getStandardPom(ReleaseUtil.java:61)
> at
> org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.getPomBackup(AbstractBackupPomsPhase.java:37)
> at
> org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.deletePomBackup(AbstractBackupPomsPhase.java:51)
> at
> org.apache.maven.shared.release.phase.CreateBackupPomsPhase.clean(CreateBackupPomsPhase.java:70)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:427)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:324)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:267)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:260)
> at
> org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:102)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
>
> [INFO] Total time: 39 seconds
> [INFO] Finished at: Thu Au
[jira] Commented: (MECLIPSE-449) Facet Generation generates duplicate entries - breaks RAD/RSA support
[ http://jira.codehaus.org/browse/MECLIPSE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135340#action_135340 ] Chris Graham commented on MECLIPSE-449: --- As a further follow up: The pom of this project (which is an EJB project) had a packaging of type: JAR, not EJB. Once that was done, the generated facet settings files was: Which removes my concerns about the utility project. This is the build section from the pom is now: maven-eclipse-plugin 1.5 org.eclipse.wst.validation.validationbuilder org.eclipse.wst.common.project.facet.core.builder org.eclipse.wst.common.project.facet.core.nature org.eclipse.wst.common.modulecore.ModuleCoreNature org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v6.1 JRE org.eclipse.jst.server.core.container/com.ibm.ws.ast.st.runtime.runtimeTarget.v61/was.base.v61 org.eclipse.jst.j2ee.internal.module.container 6.1 > Facet Generation generates duplicate entries - breaks RAD/RSA support > - > > Key: MECLIPSE-449 > URL: http://jira.codehaus.org/browse/MECLIPSE-449 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.5.1 > Environment: WinXP, IBM RSA V7.0.0.6 (Eclipse 3.2.2) >Reporter: Chris Graham > > Using V2.5.1 of the maven-eclipse-plugin, I have some issues in getting the > generated artifacts being correct. > Take this section of the POM: > > 5.0 > 2.1 > 6.1 > > Generates this: > > > > > > > > > > You'll see that the jst.java facet is in there twice. > Removing the facet from the list: > > 2.1 > 6.1 > > Generates this: > > > > > > > > > Which is a little more correct. > I consider this a bug, as the facets (by their very definition) are unique > and should not be repeated. > Additionally, when compared to a RSA (V7) generated one, it is missing the > standard XML header: > > Also, where does the jst.utility facet come from? > It's inclusion is getting in the way of RSA recognising it as a true J2EE > component project (the EJB Deployment descriptor tree element does not > display in the Project Explorer view in the J2EE Perspective). > This is the complete RSA generated one, for reference: > > > > > > > > > > (Which raises another question, how do we specify the runtime items and if > something is fixed or not?) > However, to get it to be correctly recognised, all we need is this: > > > > > > -- 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-3571) Allow use of ! when deactivating profiles
[
http://jira.codehaus.org/browse/MNG-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135341#action_135341
]
Paul Gier commented on MNG-3571:
The site was updated with a description of the ! syntax in this commit:
http://www.nabble.com/svn-commit%3A-r656894maven-site-trunk-src-site-apt-guides-introduction-introduction-to-profiles.apt-ts17264759.html
I'll add something about the +/- syntax also.
> Allow use of ! when deactivating profiles
> -
>
> Key: MNG-3571
> URL: http://jira.codehaus.org/browse/MNG-3571
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Reporter: Paul Gier
>Assignee: Paul Gier
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
>
> The current syntax for deactivating a profile from the command line is:
> {{mvn -P-myProfile}}
> It would be more intuitive if the exclamation point could be used in addition
> to the dash.
> {{mvn -P!myProfile}}
--
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: (MPLUGIN-114) PluginXdocGenerator NullPointerException
[ http://jira.codehaus.org/browse/MPLUGIN-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135343#action_135343 ] Garvin LeClaire commented on MPLUGIN-114: - I am digging in the Groovy plugin code to confirm if there is an bug there. Thanks. > PluginXdocGenerator NullPointerException > > > Key: MPLUGIN-114 > URL: http://jira.codehaus.org/browse/MPLUGIN-114 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API >Affects Versions: 2.3 >Reporter: Garvin LeClaire >Assignee: Benjamin Bentmann > Fix For: 2.4.2 > > Attachments: pom.xml > > > When creating a site I get the following stack trace: > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.tools.plugin.generator.PluginXdocGenerator.execute(PluginXdocGenerator.java:95) > at > org.apache.maven.plugin.plugin.PluginReport.generatePluginDocumentation(PluginReport.java:224) > at > org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:178) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 33 seconds > [INFO] Finished at: Wed May 14 23:36:51 EDT 2008 > [INFO] Final Memory: 41M/63M > I have tried and get the same results with version of the site plg-in back to > 2.0-beta-3 > Any suggestions?? -- 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: (WAGON-109) Refactor Wagon HTTP and Wagon WebDav
[ http://jira.codehaus.org/browse/WAGON-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135347#action_135347 ] Brett Porter commented on WAGON-109: also need to re-test deploying sites > Refactor Wagon HTTP and Wagon WebDav > > > Key: WAGON-109 > URL: http://jira.codehaus.org/browse/WAGON-109 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-webdav >Reporter: James William Dumay >Assignee: Brett Porter > Fix For: 1.0-beta-3 > > Attachments: webdav-http-dav-refactor.patch, > webdav-http-dav-refactor.patch, webdav-http-dav-refactor.patch > > > This patch includes the following: > * Webdav wagon is now using Jackrabbits webdav client implementation over the > Apache Slide client library (now defunct) > * Inclusion of a commons HttpClient abstract wagon for code reuse between > Wagon Http and Wagon Dav. > * Improved consistency of http parameters across Wagon HTTP and Wagon Webdav > methods -- 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-3584) possible new memory leak in Maven 2.0.9
possible new memory leak in Maven 2.0.9 --- Key: MNG-3584 URL: http://jira.codehaus.org/browse/MNG-3584 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.9 Reporter: Brett Porter see thread: http://mail-archives.apache.org/mod_mbox/maven-users/200805.mbox/[EMAIL PROTECTED] There seems to be some evidence of a change in 2.0.9 that has increased memory consumption. -- 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
