[jira] (MNGSITE-168) http://maven.apache.org/maven-v4_0_0.xsd not accessible
[ https://jira.codehaus.org/browse/MNGSITE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNGSITE-168. -- Resolution: Not A Bug Assignee: Robert Scholte It should be http://maven.apache.org/xsd/maven-4.0.0.xsd Is there any documentation which refers to your URL? http://maven.apache.org/maven-v4_0_0.xsd not accessible --- Key: MNGSITE-168 URL: https://jira.codehaus.org/browse/MNGSITE-168 Project: Maven Project Web Site Issue Type: Bug Environment: Firefox, wget Reporter: Mathieu Baudier Assignee: Robert Scholte http://maven.apache.org/maven-v4_0_0.xsd doesn't seem to be accessible anymore. We use it in our POMs as XML grammar. Has it moved? $ wget http://maven.apache.org/maven-v4_0_0.xsd --2013-01-12 19:06:38-- http://maven.apache.org/maven-v4_0_0.xsd Resolving maven.apache.org... 140.211.11.131, 192.87.106.229, 2001:610:1:80bc:192:87:106:229 Connecting to maven.apache.org|140.211.11.131|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2013-01-12 19:06:38 ERROR 404: Not Found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-360) JavaDoc aggregation fails (ignores deployed snapshots, complains that release versions don't satisfy the version range)
[
https://jira.codehaus.org/browse/MJAVADOC-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317205#comment-317205
]
Robert Scholte commented on MJAVADOC-360:
-
For the one willing to pick this this up: The
{{DefaultRepositoryMetadataManager}} is a possible cause. Maybe this says it
all:
http://maven.apache.org/ref/3.0.4/maven-compat/xref/org/apache/maven/artifact/repository/metadata/DefaultRepositoryMetadataManager.html#217
That would explain why the SNAPSHOT's aren't merged.
JavaDoc aggregation fails (ignores deployed snapshots, complains that release
versions don't satisfy the version range)
---
Key: MJAVADOC-360
URL: https://jira.codehaus.org/browse/MJAVADOC-360
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.8.1
Environment: Apache Maven 3.0.4
(rNON-CANONICAL_2012-01-24_13-02_root; 2012-01-24 13:02:02+)
Maven home: /opt/maven
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: linux, version: 3.6.11-1-arch, arch: amd64, family: unix
java version 1.6.0_24
OpenJDK Runtime Environment (IcedTea6 1.11.5)
(ArchLinux-6.b24_1.11.5-1-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
Reporter: Mark R
A multi-module project that uses a few deployed snapshots is now failing to
build due to the javadoc aggregator giving the following error:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:aggregate
(aggregate) on project io7m-jcanephora: An error has occurred in
JavaDocs report generation: Unable to find a version in [2.0.0, 2.1.0,
2.1.1, 2.1.2, 2.2.0, 2.3.0] to match the range
[2.4.0-SNAPSHOT,2.4.0-SNAPSHOT],[2.4.0,3.0.0) [ERROR]
com.io7m.jaux:io7m-jaux:jar:null
Essentially, the aggregator seems to be saying that only the released
versions (on the Central repository) are being considered for use, and they
don't fall within the range given by the dependency on the snapshot version
of that package (io7m-jaux).
This was originally discussed on the mailing list here (to no resolution, but
it was suggested that I open this issue):
https://mail-archives.apache.org/mod_mbox/maven-users/201301.mbox/%3c20130108140632.851a...@athena.apache.org%3E
I have uploaded a snapshot of the project to the github repository at:
https://github.com/io7m/io7m-jcanephora
The README file gives two required public repositories necessary to build the
project, and recommends the use of -Dmaven.test.skip=true (as the test suite
is quite intensive and not needed here). I've been building with mvn -C
clean verify -Dmaven.test.skip=true.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-702) Incorrect documentation for parameter skip of goal check-local-modification of the plugin
[ https://jira.codehaus.org/browse/SCM-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed SCM-702. -- Resolution: Fixed Fix Version/s: 1.9 Assignee: Robert Scholte Fixed in [bb864ac1|http://git-wip-us.apache.org/repos/asf/maven-scm/commit/bb864ac1] Incorrect documentation for parameter skip of goal check-local-modification of the plugin - Key: SCM-702 URL: https://jira.codehaus.org/browse/SCM-702 Project: Maven SCM Issue Type: Bug Components: documentation, maven-plugin Affects Versions: 1.8.1 Reporter: Maarten van Schouwen Assignee: Robert Scholte Priority: Minor Fix For: 1.9 The documentation for the parameter skip of goal check-local-modification of the plugin is incorrect. Currently it is a copy of the documentation for parameter errorMessage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-636) Provide documentation about connection and developerConnection
[ https://jira.codehaus.org/browse/SCM-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed SCM-636. -- Resolution: Fixed Fix Version/s: 1.9 Assignee: Robert Scholte Fixed in [fd487ab9|http://git-wip-us.apache.org/repos/asf/maven-scm/commit/fd487ab9] Provide documentation about connection and developerConnection -- Key: SCM-636 URL: https://jira.codehaus.org/browse/SCM-636 Project: Maven SCM Issue Type: Improvement Components: documentation Affects Versions: 1.5 Reporter: Alberto Gallardo Assignee: Robert Scholte Priority: Minor Fix For: 1.9 I couldn't find any documentation in the official site about the different *connection* and *developerConnection*. What are the differences between them? When and how to use them? Is this scm-dependent? etc. This info should be added to the [usage page|http://maven.apache.org/scm/maven-scm-plugin/usage.html]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-168) http://maven.apache.org/maven-v4_0_0.xsd not accessible
[ https://jira.codehaus.org/browse/MNGSITE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNGSITE-168. -- Resolution: Fixed The number of references it too huge to simply ignore. I've added a redirect for it. http://maven.apache.org/maven-v4_0_0.xsd not accessible --- Key: MNGSITE-168 URL: https://jira.codehaus.org/browse/MNGSITE-168 Project: Maven Project Web Site Issue Type: Bug Environment: Firefox, wget Reporter: Mathieu Baudier Assignee: Robert Scholte http://maven.apache.org/maven-v4_0_0.xsd doesn't seem to be accessible anymore. We use it in our POMs as XML grammar. Has it moved? $ wget http://maven.apache.org/maven-v4_0_0.xsd --2013-01-12 19:06:38-- http://maven.apache.org/maven-v4_0_0.xsd Resolving maven.apache.org... 140.211.11.131, 192.87.106.229, 2001:610:1:80bc:192:87:106:229 Connecting to maven.apache.org|140.211.11.131|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2013-01-12 19:06:38 ERROR 404: Not Found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-572) CVS checkout using maven-scm-plugin is not working
[
https://jira.codehaus.org/browse/SCM-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-572:
---
Component/s: maven-scm-provider-cvs
Description:
I am using {{maven-scm-plugin}} plugin and using {{developerconnection}}. which
has following values
{code:xml}
developerConnectionscm:cvs:pserver:USER:password#@IDADRESS:PORT:/home/cvs:${checkout.module}/developerConnection
{code}
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.3/version
executions
execution
configuration
connectionTypedeveloperConnection/connectionType
scmVersionType${cvsTrunkVersion}/scmVersionType
scmVersion${cvsBranchTag}/scmVersion
checkoutDirectory${checkout.destination.dir}/checkoutDirectory
/configuration
phaseprocess-resources/phase
goals
goalcheckout/goal
/goals
/execution
/executions
/plugin
{code}
was:
I am using maven-scm-plugin plugin and using developerconnection. which has
following values
developerConnectionscm:cvs:pserver:USER:password#@IDADRESS:PORT:/home/cvs:${checkout.module}/developerConnection
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.3/version
executions
execution
configuration
connectionTypedeveloperConnection/connectionType
scmVersionType${cvsTrunkVersion}/scmVersionType
scmVersion${cvsBranchTag}/scmVersion
checkoutDirectory${checkout.destination.dir}/checkoutDirectory
/configuration
phaseprocess-resources/phase
goals
goalcheckout/goal
/goals
/execution
/executions
/plugin
CVS checkout using maven-scm-plugin is not working
--
Key: SCM-572
URL: https://jira.codehaus.org/browse/SCM-572
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-cvs
Reporter: Monica Dube
I am using {{maven-scm-plugin}} plugin and using {{developerconnection}}.
which has following values
{code:xml}
developerConnectionscm:cvs:pserver:USER:password#@IDADRESS:PORT:/home/cvs:${checkout.module}/developerConnection
{code}
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.3/version
executions
execution
configuration
connectionTypedeveloperConnection/connectionType
scmVersionType${cvsTrunkVersion}/scmVersionType
scmVersion${cvsBranchTag}/scmVersion
checkoutDirectory${checkout.destination.dir}/checkoutDirectory
/configuration
phaseprocess-resources/phase
goals
goalcheckout/goal
/goals
/execution
/executions
/plugin
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-572) CVS checkout using maven-scm-plugin is not working
[
https://jira.codehaus.org/browse/SCM-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed SCM-572.
--
Resolution: Cannot Reproduce
Assignee: Robert Scholte
See http://maven.apache.org/scm/cvs.html for all options.
CVS checkout using maven-scm-plugin is not working
--
Key: SCM-572
URL: https://jira.codehaus.org/browse/SCM-572
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-cvs
Reporter: Monica Dube
Assignee: Robert Scholte
I am using {{maven-scm-plugin}} plugin and using {{developerconnection}}.
which has following values
{code:xml}
developerConnectionscm:cvs:pserver:USER:password#@IDADRESS:PORT:/home/cvs:${checkout.module}/developerConnection
{code}
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.3/version
executions
execution
configuration
connectionTypedeveloperConnection/connectionType
scmVersionType${cvsTrunkVersion}/scmVersionType
scmVersion${cvsBranchTag}/scmVersion
checkoutDirectory${checkout.destination.dir}/checkoutDirectory
/configuration
phaseprocess-resources/phase
goals
goalcheckout/goal
/goals
/execution
/executions
/plugin
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-580) Maven SCM plugin configuration ignored if executions are used.
[
https://jira.codehaus.org/browse/SCM-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-580:
---
Component/s: maven-plugin
Description:
When utilizing the embedded configuration tag, everything is perfect. However,
once I try to use executions, the plugin fails to recognize the settings
specified in within the execution tag. Here is the portion of my pom file that
doesn't work:
{code:xml}
profile
idbootstrap-all/id
activation
activeByDefaulttrue/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.4/version
configuration
skipCheckoutIfExists/
/configuration
executions
execution
idcheckout_a/id
configuration
connectionUrlscm:svn:https://svnserver/svn/prod/java/aws-core-webutils/trunk//connectionUrl
checkoutDirectory${basedir}..\aws-core-webutils/checkoutDirectory
/configuration
phaseprocess-resources/phase
goals
goalcheckout/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
However, this does work:
{code:xml}
profile
idbootstrap-all/id
activation
activeByDefaulttrue/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.4/version
configuration
skipCheckoutIfExists/
connectionUrlscm:svn:https://svnserver/svn/prod/java/aws-core-webutils/trunk//connectionUrl
checkoutDirectory${basedir}\..\aws-core-webutils/checkoutDirectory
/configuration
/plugin
/plugins
/build
/profile
{code}
was:
When utilizing the embedded configuration tag, everything is perfect. However,
once I try to use executions, the plugin fails to recognize the settings
specified in within the execution tag. Here is the portion of my pom file that
doesn't work:
profile
idbootstrap-all/id
activation
activeByDefaulttrue/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.4/version
configuration
skipCheckoutIfExists/
/configuration
executions
execution
idcheckout_a/id
configuration
[jira] (SCM-580) Maven SCM plugin configuration ignored if executions are used.
[
https://jira.codehaus.org/browse/SCM-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed SCM-580.
--
Resolution: Not A Bug
Assignee: Robert Scholte
Maven SCM plugin configuration ignored if executions are used.
--
Key: SCM-580
URL: https://jira.codehaus.org/browse/SCM-580
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin
Affects Versions: 1.4
Environment: Windows
Reporter: Lee Fox
Assignee: Robert Scholte
When utilizing the embedded configuration tag, everything is perfect.
However, once I try to use executions, the plugin fails to recognize the
settings specified in within the execution tag. Here is the portion of my
pom file that doesn't work:
{code:xml}
profile
idbootstrap-all/id
activation
activeByDefaulttrue/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.4/version
configuration
skipCheckoutIfExists/
/configuration
executions
execution
idcheckout_a/id
configuration
connectionUrlscm:svn:https://svnserver/svn/prod/java/aws-core-webutils/trunk//connectionUrl
checkoutDirectory${basedir}..\aws-core-webutils/checkoutDirectory
/configuration
phaseprocess-resources/phase
goals
goalcheckout/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
However, this does work:
{code:xml}
profile
idbootstrap-all/id
activation
activeByDefaulttrue/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.4/version
configuration
skipCheckoutIfExists/
connectionUrlscm:svn:https://svnserver/svn/prod/java/aws-core-webutils/trunk//connectionUrl
checkoutDirectory${basedir}\..\aws-core-webutils/checkoutDirectory
/configuration
/plugin
/plugins
/build
/profile
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-585) repository cannot be null on ScmManager.makeProviderScmRepository(String, File)
[
https://jira.codehaus.org/browse/SCM-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-585:
---
Component/s: maven-scm-api
Description:
I want to update a subversion with maven-scm.
Therefore I get the ScmManager via Plexus and then do this:
{code}
ScmManager.makeProviderScmRepository(svn, new File(path/to/checkout));
{code}
What I get is:
{noformat}
java.lang.NullPointerException: repository cannot be null
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:49)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:356)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.info(AbstractSvnScmProvider.java:377)
at
org.apache.maven.scm.provider.svn.svnexe.SvnExeScmProvider.getRepositoryURL(SvnExeScmProvider.java:150)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.makeProviderScmRepository(AbstractSvnScmProvider.java:119)
at
org.apache.maven.scm.manager.AbstractScmManager.makeProviderScmRepository(AbstractScmManager.java:267)
{noformat}
From what I understand the code tries to execute svn info to get the
repository URL.
However executing a command always checks that the repository is not {{null}}.
In this case the svn command should be executed in order to be able to create
the repository.
It is not possible to create the repository before, because the URL is not
known.
My suggestion is to revisit this block in AbstractCommand:
{code}
if ( repository == null )
{
throw new NullPointerException( repository cannot be null );
}
{code}
was:
I want to update a subversion with maven-scm.
Therefore I get the ScmManager via Plexus and then do this:
ScmManager.makeProviderScmRepository(svn, new File(path/to/checkout));
What I get is:
java.lang.NullPointerException: repository cannot be null
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:49)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:356)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.info(AbstractSvnScmProvider.java:377)
at
org.apache.maven.scm.provider.svn.svnexe.SvnExeScmProvider.getRepositoryURL(SvnExeScmProvider.java:150)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.makeProviderScmRepository(AbstractSvnScmProvider.java:119)
at
org.apache.maven.scm.manager.AbstractScmManager.makeProviderScmRepository(AbstractScmManager.java:267)
From what I understand the code tries to execute svn info to get the
repository URL.
However executing a command always checks that the repository is not null.
In this case the svn command should be executed in order to be able to create
the repository.
It is not possible to create the repository before, because the URL is not
known.
My suggestion is to revisit this block in AbstractCommand:
if ( repository == null )
{
throw new NullPointerException( repository cannot be null );
}
repository cannot be null on ScmManager.makeProviderScmRepository(String,
File)
-
Key: SCM-585
URL: https://jira.codehaus.org/browse/SCM-585
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-api
Affects Versions: 1.4
Reporter: Jörg Hohwiller
I want to update a subversion with maven-scm.
Therefore I get the ScmManager via Plexus and then do this:
{code}
ScmManager.makeProviderScmRepository(svn, new File(path/to/checkout));
{code}
What I get is:
{noformat}
java.lang.NullPointerException: repository cannot be null
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:49)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:356)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.info(AbstractSvnScmProvider.java:377)
at
org.apache.maven.scm.provider.svn.svnexe.SvnExeScmProvider.getRepositoryURL(SvnExeScmProvider.java:150)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.makeProviderScmRepository(AbstractSvnScmProvider.java:119)
at
org.apache.maven.scm.manager.AbstractScmManager.makeProviderScmRepository(AbstractScmManager.java:267)
{noformat}
From what I understand the code tries to execute svn info to get the
repository URL.
However executing a command always checks that the repository is not {{null}}.
In this case the svn command should be executed in order to be able to create
the repository.
It is not possible to create the repository before, because the URL is not
known.
My suggestion is to revisit this block in
[jira] (SCM-657) SvnExeExportCommand with revision malfunctions for moved/deleted files
[
https://jira.codehaus.org/browse/SCM-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-657:
---
Component/s: maven-scm-provider-svn
Description:
According to http://subversion.tigris.org/issues/show_bug.cgi?id=2163, which is
marked 'INVALID' @revision must be used instead of -r revision, otherwise
export does not find specified file.
Attached is a fixed implementation of {{createCommandLine}} method of
{{org.apache.maven.scm.provider.svn.svnexe.command.export.SvnExeExportCommand}}
was:
According to http://subversion.tigris.org/issues/show_bug.cgi?id=2163, which is
marked 'INVALID' @revision must be used instead of -r revision, otherwise
export does not find specified file.
Attached is a fixed implementation of createCommandLine method of
org.apache.maven.scm.provider.svn.svnexe.command.export.SvnExeExportCommand
SvnExeExportCommand with revision malfunctions for moved/deleted files
---
Key: SCM-657
URL: https://jira.codehaus.org/browse/SCM-657
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-svn
Environment: svn, version 1.6.17 (r1128011)
compiled Nov 19 2011, 08:40:40
Reporter: adam.kopecky
Attachments: fixed_method.txt, patch
According to http://subversion.tigris.org/issues/show_bug.cgi?id=2163, which
is marked 'INVALID' @revision must be used instead of -r revision, otherwise
export does not find specified file.
Attached is a fixed implementation of {{createCommandLine}} method of
{{org.apache.maven.scm.provider.svn.svnexe.command.export.SvnExeExportCommand}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-661) Initial checkout in clearcase ucm needs activity
[
https://jira.codehaus.org/browse/SCM-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-661:
---
Component/s: maven-scm-provider-clearcase
Description:
My Jenkins job is configured to create a clearcase UCM view whenever started
i.e. it is not updating a view created in previous runs.
The build tries then to release my maven project (maven-release-plugin)
First operation is to modify pom.xml. In clearcase you need to perform a
checkout in order to modify a file. However, that fails because in UCM a view
needs to have an activity set.
A workaround is to create an activity before with the corresponding cleartool
command. However, I think this should be performed by the scm plugin when asked
to perform the checkout.
My clearcase-settings.xml specifies clearcaseTypeUCM/clearcaseType
{noformat}
[INFO] [release:prepare {execution: default-cli}]
[INFO] viewName = 'AXIAZ-bnjwa029-maven' ; configSpec = 'load \Orbis_Reports' ;
vobName = '\Orbis_Project_Vob' ; streamName = 'MavenDeploymentEvaluation' ;
elementName = 'null'
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] viewName = 'AXIAZ-bnjwa029-maven' ; configSpec = 'load \Orbis_Reports' ;
vobName = '\Orbis_Project_Vob' ; streamName = 'MavenDeploymentEvaluation' ;
elementName = 'null'
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] viewName = 'AXIAZ-bnjwa029-maven' ; configSpec = 'load \Orbis_Reports' ;
vobName = '\Orbis_Project_Vob' ; streamName = 'MavenDeploymentEvaluation' ;
elementName = 'null'
[INFO] Transforming 'test-reports'...
[INFO] viewName = 'AXIAZ-bnjwa029-maven' ; configSpec = 'load \Orbis_Reports' ;
vobName = '\Orbis_Project_Vob' ; streamName = 'MavenDeploymentEvaluation' ;
elementName = 'null'
[INFO] edit file:
D:\Views\hudson_slave\workspace\TestMax\hudson_view_MavenDeploymentEvaluation\Orbis_Reports\pom.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: To operate on UCM branch, must be set to an activity and a
UCM view.
{noformat}
was:
My Jenkins job is configured to create a clearcase UCM view whenever started
i.e. it is not updating a view created in previous runs.
The build tries then to release my maven project (maven-release-plugin)
First operation is to modify pom.xml. In clearcase you need to perform a
checkout in order to modify a file. However, that fails because in UCM a view
needs to have an activity set.
A workaround is to create an activity before with the corresponding cleartool
command. However, I think this should be performed by the scm plugin when asked
to perform the checkout.
My clearcase-settings.xml specifies clearcaseTypeUCM/clearcaseType
[INFO] [release:prepare {execution: default-cli}]
[INFO] viewName = 'AXIAZ-bnjwa029-maven' ; configSpec = 'load \Orbis_Reports' ;
vobName = '\Orbis_Project_Vob' ; streamName = 'MavenDeploymentEvaluation' ;
elementName = 'null'
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] viewName = 'AXIAZ-bnjwa029-maven' ; configSpec = 'load \Orbis_Reports' ;
vobName = '\Orbis_Project_Vob' ; streamName = 'MavenDeploymentEvaluation' ;
elementName = 'null'
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] viewName = 'AXIAZ-bnjwa029-maven' ; configSpec = 'load \Orbis_Reports' ;
vobName = '\Orbis_Project_Vob' ; streamName = 'MavenDeploymentEvaluation' ;
elementName = 'null'
[INFO] Transforming 'test-reports'...
[INFO] viewName = 'AXIAZ-bnjwa029-maven' ; configSpec = 'load \Orbis_Reports' ;
vobName = '\Orbis_Project_Vob' ; streamName = 'MavenDeploymentEvaluation' ;
elementName = 'null'
[INFO] edit file:
D:\Views\hudson_slave\workspace\TestMax\hudson_view_MavenDeploymentEvaluation\Orbis_Reports\pom.xml
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: To operate on UCM branch, must be set to an activity and a
UCM view.
Initial checkout in clearcase ucm needs activity
-
Key: SCM-661
URL: https://jira.codehaus.org/browse/SCM-661
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-clearcase
Affects
[jira] (SCM-614) scm plugin does not respect maven aggregation specifications
[
https://jira.codehaus.org/browse/SCM-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-614:
---
Component/s: maven-plugin
Description:
Good morning,
According to
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Aggregation
documentation, the parent project now knows its modules, and if a Maven
command is invoked against the parent project, that Maven command will then be
executed to the parent's modules as well.
But it doesn't work for maven-scm-plugin.
Consider you have this kind of project
{noformat}
myProject
|-- my-module
| `-- pom.xml
`-- pom.xml
{noformat}
And you have set a project.scm.connection xml element in each {{pom.xml}}
file.
if you run {{scm:checkout}} goal in parent project (myProject in above
example), il will not run this goal in module (my-module in above example) but
only in parent project.
Kind Regards,
Thomas.
was:
Good morning,
According to
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Aggregation
documentation, the parent project now knows its modules, and if a Maven
command is invoked against the parent project, that Maven command will then be
executed to the parent's modules as well.
But it doesn't work for maven-scm-plugin.
Consider you have this kind of project
myProject
|-- my-module
| `-- pom.xml
`-- pom.xml
And you have set a project.scm.connection xml element in each pom.xml file.
if you run scm:checkout goal in parent project (myProject in above example), il
will not run this goal in module (my-module in above example) but only in
parent project.
Kind Regards,
Thomas.
scm plugin does not respect maven aggregation specifications
Key: SCM-614
URL: https://jira.codehaus.org/browse/SCM-614
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin
Affects Versions: 1.4
Reporter: Thomas Cazali
Good morning,
According to
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Aggregation
documentation, the parent project now knows its modules, and if a Maven
command is invoked against the parent project, that Maven command will then
be executed to the parent's modules as well.
But it doesn't work for maven-scm-plugin.
Consider you have this kind of project
{noformat}
myProject
|-- my-module
| `-- pom.xml
`-- pom.xml
{noformat}
And you have set a project.scm.connection xml element in each {{pom.xml}}
file.
if you run {{scm:checkout}} goal in parent project (myProject in above
example), il will not run this goal in module (my-module in above example)
but only in parent project.
Kind Regards,
Thomas.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-565) scm:validate should not fork the build
[
https://jira.codehaus.org/browse/SCM-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-565:
---
Component/s: maven-plugin
Description:
{{scm:validate}} invokes the lifecycle validate prior to calling itself.
but this adds no benifit and just slows down the build (esp if {{scm:validate}}
is bound to the validate phase!)
That is {{scm:validate}} should only be validating the scm information in the
POM - if other plugins such as the enforcer fail due to incorrect deps this
should not cause {{mvn:validate}} to fail!
was:
scm:validate invokes the lifecycle validate prior to calling itself.
but this adds no benifit and just slows down the build (esp if scm:validate is
bound to the validate phase!)
That is scm:validate should only be validating the scm information in the POM -
if other plugins such as the enforcer fail due to incorrect deps this should
not cause mvn:validate to fail!
scm:validate should not fork the build
--
Key: SCM-565
URL: https://jira.codehaus.org/browse/SCM-565
Project: Maven SCM
Issue Type: Improvement
Components: maven-plugin
Affects Versions: 1.3
Reporter: James Nord
{{scm:validate}} invokes the lifecycle validate prior to calling itself.
but this adds no benifit and just slows down the build (esp if
{{scm:validate}} is bound to the validate phase!)
That is {{scm:validate}} should only be validating the scm information in the
POM - if other plugins such as the enforcer fail due to incorrect deps this
should not cause {{mvn:validate}} to fail!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-565) scm:validate should not fork the build
[
https://jira.codehaus.org/browse/SCM-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317228#comment-317228
]
Robert Scholte commented on SCM-565:
Looking at the current state of the
[ValidateMojo|http://maven.apache.org/scm/maven-scm-plugin/xref/org/apache/maven/scm/plugin/ValidateMojo.html]
I don't recognize your issue. Can we close it?
scm:validate should not fork the build
--
Key: SCM-565
URL: https://jira.codehaus.org/browse/SCM-565
Project: Maven SCM
Issue Type: Improvement
Components: maven-plugin
Affects Versions: 1.3
Reporter: James Nord
{{scm:validate}} invokes the lifecycle validate prior to calling itself.
but this adds no benifit and just slows down the build (esp if
{{scm:validate}} is bound to the validate phase!)
That is {{scm:validate}} should only be validating the scm information in the
POM - if other plugins such as the enforcer fail due to incorrect deps this
should not cause {{mvn:validate}} to fail!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-665) TfsChangeLogCommand does not display the change log for directories
[
https://jira.codehaus.org/browse/SCM-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-665:
---
Component/s: maven-scm-provider-tfs
Description:
The {{TfsChangeLogCommand}} can get change log of specific file(s), but cannot
work for directory.
In {{TfsChangeLogCommand.java}} of version 1.6, line 83 is
{code}command.addArgument( file.getName() ); {code}
But I believe it should be
{code}command.addArgument( file.getAbsolutePath() ); {code}
was:
The TfsChangeLogCommand can get change log of specific file(s), but cannot work
for directory.
In TfsChangeLogCommand.java of version 1.6, line 83 is
command.addArgument( file.getName() );
But I believe it should be
command.addArgument( file.getAbsolutePath() );
TfsChangeLogCommand does not display the change log for directories
---
Key: SCM-665
URL: https://jira.codehaus.org/browse/SCM-665
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-tfs
Affects Versions: 1.6
Reporter: John Wu
The {{TfsChangeLogCommand}} can get change log of specific file(s), but
cannot work for directory.
In {{TfsChangeLogCommand.java}} of version 1.6, line 83 is
{code}command.addArgument( file.getName() ); {code}
But I believe it should be
{code}command.addArgument( file.getAbsolutePath() ); {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-267) Branches setting is being used as a tag
[
https://jira.codehaus.org/browse/SCM-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-267:
---
Component/s: maven-scm-provider-svn
maven-plugin
Description:
Using pom build of :
{code:xml}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.0-beta-4/version
configuration
!--
branchpremaven
/branch
--
/configuration
/plugin
/plugins
/build
{code}
returns :
{noformat}
[ERROR] svn: URL 'svn://172.22.248.151/svn/dirty/pcs/tags/premaven' doesn't
exist
{noformat}
as you can see.. it is looking in tags for my branch, not branches. It should
be looking in 'svn://172.22.248.151/svn/dirty/pcs/branches/premaven'
was:
Using pom build of :
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.0-beta-4/version
configuration
!--
branchpremaven
/branch
--
/configuration
/plugin
/plugins
/build
returns :
[ERROR] svn: URL 'svn://172.22.248.151/svn/dirty/pcs/tags/premaven' doesn't
exist
as you can see.. it is looking in tags for my branch, not branches. It should
be looking in 'svn://172.22.248.151/svn/dirty/pcs/branches/premaven'
Branches setting is being used as a tag
---
Key: SCM-267
URL: https://jira.codehaus.org/browse/SCM-267
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin, maven-scm-provider-svn
Affects Versions: 1.0-beta-4
Environment: Windows XP
Reporter: Damon Jacobsen
Fix For: future
Using pom build of :
{code:xml}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.0-beta-4/version
configuration
!--
branchpremaven
/branch
--
/configuration
/plugin
/plugins
/build
{code}
returns :
{noformat}
[ERROR] svn: URL 'svn://172.22.248.151/svn/dirty/pcs/tags/premaven' doesn't
exist
{noformat}
as you can see.. it is looking in tags for my branch, not branches. It should
be looking in 'svn://172.22.248.151/svn/dirty/pcs/branches/premaven'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-666) TfsEditCommand should not report error if the file is also checked out by others
[
https://jira.codehaus.org/browse/SCM-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-666:
---
Component/s: maven-scm-provider-tfs
Description:
While checking out a file for editing, the {{TfsEditCommand}} reports error, if
the file is already checked out by others, as the following:
{noformat}
$/path/to/the/file:
opened for edit in MMdd;username
{noformat}
One file is checked out and being editing by multiple people is quite common in
a team environment, which should not prevent yet another from checking it out
for editing successfully.
was:
While checking out a file for editing, the TfsEditCommand reports error, if the
file is already checked out by others, as the following:
$/path/to/the/file:
opened for edit in MMdd;username
One file is checked out and being editing by multiple people is quite common in
a team environment, which should not prevent yet another from checking it out
for editing successfully.
TfsEditCommand should not report error if the file is also checked out by
others
Key: SCM-666
URL: https://jira.codehaus.org/browse/SCM-666
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-tfs
Affects Versions: 1.6
Reporter: John Wu
While checking out a file for editing, the {{TfsEditCommand}} reports error,
if the file is already checked out by others, as the following:
{noformat}
$/path/to/the/file:
opened for edit in MMdd;username
{noformat}
One file is checked out and being editing by multiple people is quite common
in a team environment, which should not prevent yet another from checking it
out for editing successfully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-710) Use of encrypted password in pom.xml confiuration is ignored
[
https://jira.codehaus.org/browse/SCM-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-710:
---
Component/s: maven-plugin
Use of encrypted password in pom.xml confiuration is ignored
Key: SCM-710
URL: https://jira.codehaus.org/browse/SCM-710
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin
Reporter: Eddie Webb
THe docs for this plugin say I can use encrypted passwords just like we do
for the release plugin.
It does not seem to support the same
project.scm.idnon-hostname-id/project.scm.id that the release plugin
does, so I included the username and encrypted password directory in the
plugin config.
{noformat}
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.8.1/version
configuration
usernameusername/username
password{EncycptedStringGeneratedFromMvnPassword=}/password
/configuration
/plugin
/plugins
...
{noformat}
But the SCM fails with authentication issue, and the SVN logs determine that
no user ID is sent.
If I instead include the hostname as a server ID in settings.xml, or include
these values on the command line, in both cases it invokes a 500 from the
application server.
mvn scm:checkout -Pforge -Dusername=myuser
-Dpassword={EncycptedStringGeneratedFromMvnPassword=}
svn: Server sent unexpected return value (500 Internal Server Error) in
response to OPTIONS request for https://my-svn
This 500 can be duplicated in a browser by passing the un-encrypted string
{foo=}.
h3. summary
regardless of where I place the encruypted password it is either ignored, or
not decrypted before being sent to the webserver.
Can you please document an example of how to use the encrypted passwords, or
support the same approach as the release plugin.
http://jira.codehaus.org/browse/MRELEASE-420
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-423) when I try to checkout file from perforce with maven, I get an exception Perforce password (P4PASSWD) invalid or unset.
[
https://jira.codehaus.org/browse/SCM-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-423:
---
Description:
Hi all,
I'm using {{maven scm plugin 1.1}} and Perforce for building, when I try to
checkout code from Perforce it get the following exception: can anyone help ?
I've logged in before I run mvn {{scm:checkout}} command.
{noformat}
D:\mvn scm:checkout
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'scm'.
[INFO] ---
[INFO] Building BSGCommon
[INFO]task-segment: [scm:checkout] (aggregator-style)
[INFO] ---
[INFO] [scm:checkout]
[INFO] Removing D:\target\checkout
[INFO] ---
[ERROR] BUILD ERROR
[INFO] ---
[INFO] Cannot run checkout command :
Embedded error: Can't login.
Perforce password (P4PASSWD) invalid or unset.
[INFO] ---
[INFO] For more information, run Maven with the -e switch
[INFO] ---
[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Oct 22 15:53:25 IST 2008
[INFO] Final Memory: 6M/13M
[INFO] ---
{noformat}
was:
Hi all,
I'm using maven scm plugin 1.1 and Perforce for building, when I try to
checkout code from Perforce it get the following exception: can anyone help ?
I've logged in before I run mvn scm:checkout command.
D:\mvn scm:checkout
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'scm'.
[INFO] ---
[INFO] Building BSGCommon
[INFO]task-segment: [scm:checkout] (aggregator-style)
[INFO] ---
[INFO] [scm:checkout]
[INFO] Removing D:\target\checkout
[INFO] ---
[ERROR] BUILD ERROR
[INFO] ---
[INFO] Cannot run checkout command :
Embedded error: Can't login.
Perforce password (P4PASSWD) invalid or unset.
[INFO] ---
[INFO] For more information, run Maven with the -e switch
[INFO] ---
[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Oct 22 15:53:25 IST 2008
[INFO] Final Memory: 6M/13M
[INFO] ---
when I try to checkout file from perforce with maven, I get an exception
Perforce password (P4PASSWD) invalid or unset.
-
Key: SCM-423
URL: https://jira.codehaus.org/browse/SCM-423
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.1
Environment: windowsxp,
Reporter: alex zh
Hi all,
I'm using {{maven scm plugin 1.1}} and Perforce for building, when I try to
checkout code from Perforce it get the following exception: can anyone help ?
I've logged in before I run mvn {{scm:checkout}} command.
{noformat}
D:\mvn scm:checkout
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'scm'.
[INFO] ---
[INFO] Building BSGCommon
[INFO]task-segment: [scm:checkout] (aggregator-style)
[INFO] ---
[INFO] [scm:checkout]
[INFO] Removing D:\target\checkout
[INFO] ---
[ERROR] BUILD ERROR
[INFO] ---
[INFO] Cannot run checkout command :
Embedded error: Can't login.
Perforce password (P4PASSWD) invalid or unset.
[INFO] ---
[INFO] For more information, run Maven with the -e switch
[INFO] ---
[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Oct 22 15:53:25 IST 2008
[INFO] Final Memory: 6M/13M
[INFO] ---
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
[jira] (SCM-423) when I try to checkout file from perforce with maven, I get an exception Perforce password (P4PASSWD) invalid or unset.
[
https://jira.codehaus.org/browse/SCM-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-423:
---
Component/s: maven-scm-provider-perforce
when I try to checkout file from perforce with maven, I get an exception
Perforce password (P4PASSWD) invalid or unset.
-
Key: SCM-423
URL: https://jira.codehaus.org/browse/SCM-423
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.1
Environment: windowsxp,
Reporter: alex zh
Hi all,
I'm using {{maven scm plugin 1.1}} and Perforce for building, when I try to
checkout code from Perforce it get the following exception: can anyone help ?
I've logged in before I run mvn {{scm:checkout}} command.
{noformat}
D:\mvn scm:checkout
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'scm'.
[INFO] ---
[INFO] Building BSGCommon
[INFO]task-segment: [scm:checkout] (aggregator-style)
[INFO] ---
[INFO] [scm:checkout]
[INFO] Removing D:\target\checkout
[INFO] ---
[ERROR] BUILD ERROR
[INFO] ---
[INFO] Cannot run checkout command :
Embedded error: Can't login.
Perforce password (P4PASSWD) invalid or unset.
[INFO] ---
[INFO] For more information, run Maven with the -e switch
[INFO] ---
[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Oct 22 15:53:25 IST 2008
[INFO] Final Memory: 6M/13M
[INFO] ---
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-426) Got an issue in Maven plugin with perforce passowrd,suddenely now build is failing as it started to ask passowrd for scm plugin by throwing an Exception while running SCM command
[
https://jira.codehaus.org/browse/SCM-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-426:
---
Component/s: maven-scm-provider-perforce
Description:
Looking for step by step process to tackle this.
{noformat}
[INFO] [release:prepare]
[INFO] Verifying that there are no local modifications...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An error occurred during the status check process: Exception while
executing SCM command.
password is required for the perforce scm plugin.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 seconds
{noformat}
was:
Looking for step by step process to tackle this.
INFO] [release:prepare]
[INFO] Verifying that there are no local modifications...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An error occurred during the status check process: Exception while
executing SCM command.
password is required for the perforce scm plugin.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 seconds
Got an issue in Maven plugin with perforce passowrd,suddenely now build is
failing as it started to ask passowrd for scm plugin by throwing an Exception
while running SCM command
--
Key: SCM-426
URL: https://jira.codehaus.org/browse/SCM-426
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Environment: Fedora
Reporter: Praveen Marakkoor
Looking for step by step process to tackle this.
{noformat}
[INFO] [release:prepare]
[INFO] Verifying that there are no local modifications...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An error occurred during the status check process: Exception while
executing SCM command.
password is required for the perforce scm plugin.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 4 seconds
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-819) preparationGoals parameter supoorted before version 2.4
[ https://jira.codehaus.org/browse/MRELEASE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-819. --- Resolution: Fixed Fix Version/s: 2.4.1 Assignee: Robert Scholte Fixed in [r1432640|http://svn.apache.org/viewvc?rev=1432640view=rev] preparationGoals parameter supoorted before version 2.4 --- Key: MRELEASE-819 URL: https://jira.codehaus.org/browse/MRELEASE-819 Project: Maven 2.x Release Plugin Issue Type: Bug Components: documentation Affects Versions: 2.4 Reporter: Gabriel Belingueres Assignee: Robert Scholte Priority: Trivial Fix For: 2.4.1 In the 2.4 documentation, it says the preparationGoals parameter is available since 2.4, however I've been using it in previous plugin version 2.3.2 already. http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#preparationGoals -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-814:
Priority: Critical (was: Blocker)
Lowering to critical, since there's a workaround.
Property interpolation of developerConnection broken when inheritting from
parent
-
Key: MRELEASE-814
URL: https://jira.codehaus.org/browse/MRELEASE-814
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare
Affects Versions: 2.0, 2.3.2, 2.4
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
Priority: Critical
Attachments: demo.project.git.release.bug.tgz
If {{developerConnection}} is setup like this in a parent and inherited:
{code:xml}
developerConnectionscm:git:git:${project.groupId}/${project.artifactId}.git/developerConnection
{code}
Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
(and perhaps other operations)
In the example project that I've included this is what it tries to do:
{noformat}
[INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly
git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
master:master
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
project ShouldSeeThisOnceOnly: Unable to commit files
[ERROR] W access for
com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
{noformat}
I've used this same method with the property directly in the project POM with
success. It seems that having it in the parent is the issue.
Note, .ssh/config setup is required for a URL of this nature:
{noformat}
host git
user git
hostname localhost
port 22
identityfile ~/.ssh/id_rsa
{noformat}
Change these, and the deploy details to suit yourself.
I sincerely hope that I'm doing something stupid and that this is not a bug
as I desperately need to do some releases and waiting for a fix wouldn't be
ideal, nor would hacking what should be inherited into each POM. Sadly, I
doubt that I'm wrong this time, as I copy pasted the exact contents from my
bogus parent into my pom, removed the parent ref, and it works as expected.
This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317239#comment-317239
]
Robert Scholte commented on MRELEASE-814:
-
By extending I mean that the folder-path to a module is added to the URL of
the connection.
I now remember that for GIT there's always exactly 1 URL, since it is only
possible to download the whole repository: there's no way to refer directly to
a specific module.
Property interpolation of developerConnection broken when inheritting from
parent
-
Key: MRELEASE-814
URL: https://jira.codehaus.org/browse/MRELEASE-814
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare
Affects Versions: 2.0, 2.3.2, 2.4
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
Priority: Critical
Attachments: demo.project.git.release.bug.tgz
If {{developerConnection}} is setup like this in a parent and inherited:
{code:xml}
developerConnectionscm:git:git:${project.groupId}/${project.artifactId}.git/developerConnection
{code}
Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
(and perhaps other operations)
In the example project that I've included this is what it tries to do:
{noformat}
[INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly
git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
master:master
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
project ShouldSeeThisOnceOnly: Unable to commit files
[ERROR] W access for
com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
{noformat}
I've used this same method with the property directly in the project POM with
success. It seems that having it in the parent is the issue.
Note, .ssh/config setup is required for a URL of this nature:
{noformat}
host git
user git
hostname localhost
port 22
identityfile ~/.ssh/id_rsa
{noformat}
Change these, and the deploy details to suit yourself.
I sincerely hope that I'm doing something stupid and that this is not a bug
as I desperately need to do some releases and waiting for a fix wouldn't be
ideal, nor would hacking what should be inherited into each POM. Sadly, I
doubt that I'm wrong this time, as I copy pasted the exact contents from my
bogus parent into my pom, removed the parent ref, and it works as expected.
This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-813) Ability to specify tag for release:perform
[ https://jira.codehaus.org/browse/MRELEASE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317240#comment-317240 ] Robert Scholte commented on MRELEASE-813: - This is something which first need to be fixed in the [SCM project|https://jira.codehaus.org/browse/SCM]. Here's the [GitCheckoutCommand|http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/xref/org/apache/maven/scm/provider/git/gitexe/command/checkout/GitCheckOutCommand.html] and here it's already a 2-step command. For your requirement someone should improve the [HgCheckOutCommand|http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-hg/xref/org/apache/maven/scm/provider/hg/command/checkout/HgCheckOutCommand.html] Ability to specify tag for release:perform -- Key: MRELEASE-813 URL: https://jira.codehaus.org/browse/MRELEASE-813 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: Mercurial, perform Affects Versions: 2.4 Reporter: Gili We need a way to specify a tag either to release:perform or the HG scm provider. http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html indicates that we should be able to release:perform from a tag without the use of release.properties but there is no way to specify a tag for the HG scm provider. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317244#comment-317244
]
Robert Scholte commented on MRELEASE-814:
-
Commit by project is supported:
[prepare#commitByProject|http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#commitByProject]
Tag by project is a feature request: MRELEASE-241
I do understand this request, since if you tag a multimodule project, for all
modules you need to know the name of the root-project to get to the tagged
sources. (And yes I'm talking svn/cvs right now and assuming you're just
browsing based on the tags-folder).
Property interpolation of developerConnection broken when inheritting from
parent
-
Key: MRELEASE-814
URL: https://jira.codehaus.org/browse/MRELEASE-814
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare
Affects Versions: 2.0, 2.3.2, 2.4
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
Priority: Critical
Attachments: demo.project.git.release.bug.tgz
If {{developerConnection}} is setup like this in a parent and inherited:
{code:xml}
developerConnectionscm:git:git:${project.groupId}/${project.artifactId}.git/developerConnection
{code}
Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
(and perhaps other operations)
In the example project that I've included this is what it tries to do:
{noformat}
[INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly
git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
master:master
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
project ShouldSeeThisOnceOnly: Unable to commit files
[ERROR] W access for
com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
{noformat}
I've used this same method with the property directly in the project POM with
success. It seems that having it in the parent is the issue.
Note, .ssh/config setup is required for a URL of this nature:
{noformat}
host git
user git
hostname localhost
port 22
identityfile ~/.ssh/id_rsa
{noformat}
Change these, and the deploy details to suit yourself.
I sincerely hope that I'm doing something stupid and that this is not a bug
as I desperately need to do some releases and waiting for a fix wouldn't be
ideal, nor would hacking what should be inherited into each POM. Sadly, I
doubt that I'm wrong this time, as I copy pasted the exact contents from my
bogus parent into my pom, removed the parent ref, and it works as expected.
This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIASITETOOLS-78) Velocity's ContextTool fails to configure
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed DOXIASITETOOLS-78.
Resolution: Duplicate
Assignee: Robert Scholte
Considering this as a duplicate of DOXIASITETOOLS-67. Standalone it works fine
(there are unit-tests confirming this), but once classloaders get involved, the
wrong one is picked up.
Velocity's ContextTool fails to configure
-
Key: DOXIASITETOOLS-78
URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-78
Project: Maven Doxia Sitetools
Issue Type: Bug
Components: Doc renderer
Affects Versions: 1.3
Environment: Maven 2.2.1, Maven Site Plugin 3.2
Reporter: Michael Osipov
Assignee: Robert Scholte
Priority: Critical
Attachments: Velocity merge exception.png
The newly introduced ToolManager creates an unusable {{ContextTool}}.
I have defined this property in {{pom.xml/project/properties}} section:
{code:xml}
maven.compiler.target1.6/maven.compiler.target
{code}
As per doc, all properties are available in the Velocity context. It simply
does not matter whether you say {{$context}} or {{$context.get(...)}} in
your apt.vm template, it fails with runtime exception from
{{velocity.getEngine().mergeTemplate( resource,
siteContext.getInputEncoding(), vc, sw );}}
See attached screenshot.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-820) Upgrade Plexus Utils dependency
[ https://jira.codehaus.org/browse/MRELEASE-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-820. --- Resolution: Fixed Fix Version/s: 2.4.1 Assignee: Robert Scholte Fixed in [r1433030|http://svn.apache.org/viewvc?rev=1433030view=rev] Upgrade Plexus Utils dependency --- Key: MRELEASE-820 URL: https://jira.codehaus.org/browse/MRELEASE-820 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: perform Affects Versions: 2.4 Environment: OSX Reporter: Gili Assignee: Robert Scholte Fix For: 2.4.1 Please update to Plexus Utils 3.0.10 to work around this bug on OSX: http://jira.codehaus.org/browse/PLXUTILS-156 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-565) scm:validate should not fork the build
[
https://jira.codehaus.org/browse/SCM-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed SCM-565.
--
Resolution: Fixed
Fix Version/s: 1.9
Assignee: Robert Scholte
Fixed in
[64d2d326|http://git-wip-us.apache.org/repos/asf/maven-scm/commit/64d2d326]
(I'm already used to the Mojo Annotations, just misread the doclet-tag)
scm:validate should not fork the build
--
Key: SCM-565
URL: https://jira.codehaus.org/browse/SCM-565
Project: Maven SCM
Issue Type: Improvement
Components: maven-plugin
Affects Versions: 1.3
Reporter: James Nord
Assignee: Robert Scholte
Fix For: 1.9
{{scm:validate}} invokes the lifecycle validate prior to calling itself.
but this adds no benifit and just slows down the build (esp if
{{scm:validate}} is bound to the validate phase!)
That is {{scm:validate}} should only be validating the scm information in the
POM - if other plugins such as the enforcer fail due to incorrect deps this
should not cause {{mvn:validate}} to fail!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-742) Regression in 2.2.2 related to maven-gpg-plugin
[ https://jira.codehaus.org/browse/MRELEASE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317372#comment-317372 ] Robert Scholte commented on MRELEASE-742: - Gili, what's your environment? Especially which Maven version? Regression in 2.2.2 related to maven-gpg-plugin --- Key: MRELEASE-742 URL: https://jira.codehaus.org/browse/MRELEASE-742 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.2.2 Environment: OS X 10.6, Maven 3.0.3, maven-gpg-plugin 1.4 Reporter: Andres Rodriguez After updating to Release Plugin 2.2.2 gpg plugin fails with error: Cannot obtain passphrase in batch mode Which is thrown (see http://maven.apache.org/plugins/maven-gpg-plugin/xref/org/apache/maven/plugin/gpg/AbstractGpgMojo.html) when the passphrase has not been set and the use agent parameter is false. The passphrase is set in my settings.xml and the useAgent has the default false value. Downgrading to 2.2.1 fixes the problem and the built artifacts are correctly signed. An example POM project can be found at: http://code.google.com/p/derquinse-commons/source/browse/trunk/derquinse-pom/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-742) Regression in 2.2.2 related to maven-gpg-plugin
[
https://jira.codehaus.org/browse/MRELEASE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317375#comment-317375
]
Robert Scholte commented on MRELEASE-742:
-
Maven 3.0.4 fixes an issue with {{Profile}} merging in {{settings.xml}} which
was there since the first Maven3 release. What you could try: run the project
with Maven-3.0.4, and set the
[maven-release-plugin#mavenHome|http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#mavenHome]
property to Maven-3.0.3
Regression in 2.2.2 related to maven-gpg-plugin
---
Key: MRELEASE-742
URL: https://jira.codehaus.org/browse/MRELEASE-742
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.2.2
Environment: OS X 10.6, Maven 3.0.3, maven-gpg-plugin 1.4
Reporter: Andres Rodriguez
After updating to Release Plugin 2.2.2 gpg plugin fails with error:
Cannot obtain passphrase in batch mode
Which is thrown (see
http://maven.apache.org/plugins/maven-gpg-plugin/xref/org/apache/maven/plugin/gpg/AbstractGpgMojo.html)
when the passphrase has not been set and the use agent parameter is
false. The passphrase is set in my settings.xml and the useAgent has the
default false value.
Downgrading to 2.2.1 fixes the problem and the built artifacts are correctly
signed.
An example POM project can be found at:
http://code.google.com/p/derquinse-commons/source/browse/trunk/derquinse-pom/pom.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5363) Regression for SSLv3
[ https://jira.codehaus.org/browse/MNG-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5363: Priority: Critical (was: Major) Regression for SSLv3 Key: MNG-5363 URL: https://jira.codehaus.org/browse/MNG-5363 Project: Maven 2 3 Issue Type: Bug Components: Errors Affects Versions: 3.0.4 Environment: Operation system independent, but tested on Macbook Pro with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. Reporter: James Kionka Priority: Critical When attempting to access a Maven repository which uses SSLv3, you get the following error, javax.net.ssl.SSLException: Received fatal alert: bad_record_mac. Earlier versions of Maven used java.net.URLConnection which respects the https.protocols system property. This allowed us to set it to SSLv3, which is what our Maven repository uses. However, HttpClient ignores that property. In other situations, we programmatically tell HttpClient to use SSLv3, which we cannot do from our end. You can find another person in the same situation here: http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317379#comment-317379
]
Robert Scholte commented on MRELEASE-814:
-
With a little less words that was my thought when writing The only project
which could inherit is the executionProject, all modules should extend
Property interpolation of developerConnection broken when inheritting from
parent
-
Key: MRELEASE-814
URL: https://jira.codehaus.org/browse/MRELEASE-814
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare
Affects Versions: 2.0, 2.3.2, 2.4
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
Priority: Critical
Attachments: demo.project.git.release.bug.tgz
If {{developerConnection}} is setup like this in a parent and inherited:
{code:xml}
developerConnectionscm:git:git:${project.groupId}/${project.artifactId}.git/developerConnection
{code}
Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
(and perhaps other operations)
In the example project that I've included this is what it tries to do:
{noformat}
[INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly
git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
master:master
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
project ShouldSeeThisOnceOnly: Unable to commit files
[ERROR] W access for
com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
{noformat}
I've used this same method with the property directly in the project POM with
success. It seems that having it in the parent is the issue.
Note, .ssh/config setup is required for a URL of this nature:
{noformat}
host git
user git
hostname localhost
port 22
identityfile ~/.ssh/id_rsa
{noformat}
Change these, and the deploy details to suit yourself.
I sincerely hope that I'm doing something stupid and that this is not a bug
as I desperately need to do some releases and waiting for a fix wouldn't be
ideal, nor would hacking what should be inherited into each POM. Sadly, I
doubt that I'm wrong this time, as I copy pasted the exact contents from my
bogus parent into my pom, removed the parent ref, and it works as expected.
This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-276) Read timed out during release:perform after updating to Maven 2.2
[
https://jira.codehaus.org/browse/WAGON-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated WAGON-276:
-
Description:
Artifact deployment fails with Maven 2.2:
{noformat}
[INFO] [DEBUG] Read timed out
[INFO] java.net.SocketTimeoutException: Read timed out
[INFO] at java.net.SocketInputStream.socketRead0(Native Method)
[INFO] at java.net.SocketInputStream.read(SocketInputStream.java:129)
[INFO] at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
[INFO] at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
[INFO] at
hidden.org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
[INFO] at
hidden.org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
[INFO] at
hidden.org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
[INFO] at
hidden.org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
[INFO] at
hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
[INFO] at
hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
[INFO] at
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:446)
[INFO] at
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:330)
[INFO] at
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280)
[INFO] at
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262)
[INFO] at
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172)
[INFO] at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
[INFO] at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173)
[INFO] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
[INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
[INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
[INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
[INFO] at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
[INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO] at java.lang.reflect.Method.invoke(Method.java:597)
[INFO] at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[INFO] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[INFO] at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[INFO] at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] [INFO]
[INFO] [ERROR] BUILD ERROR
[INFO] [INFO]
[INFO] [INFO] Error deploying artifact: Read timed out
[INFO]
[INFO] [INFO]
[INFO] [DEBUG] Trace
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifact: Read timed out
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
[INFO] at
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-146:
-
Description:
Consider the following dependency tree:
{noformat}
A
+- B
| \-X (1.1)
+- C
\-X (2.1)
{noformat}
I can use the requireUpperBoundDeps to find these types of issues (I want to
use D 2.1 rather than 1.1).
To fix the issue I use dependencyManagement to set the version of X to 2.1.
As I understand it, using dependencyManagement effectively changes the tree to
look like this:
{noformat}
A
+- B
| \-X (2.1) (really 1.1, but managed to 2.1)
+- C
\-X (2.1)
{noformat}
Now, if B is upgraded to depend on X 2.5, I will never know:
{noformat}
A
+- B
| \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
+- C
\-X (2.1)
{noformat}
was:
Consider the following dependency tree:
A
+- B
| \-X (1.1)
+- C
\-X (2.1)
I can use the requireUpperBoundDeps to find these types of issues (I want to
use D 2.1 rather than 1.1).
To fix the issue I use dependencyManagement to set the version of X to 2.1.
As I understand it, using dependencyManagement effectively changes the tree to
look like this:
A
+- B
| \-X (2.1) (really 1.1, but managed to 2.1)
+- C
\-X (2.1)
Now, if B is upgraded to depend on X 2.5, I will never know:
A
+- B
| \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
+- C
\-X (2.1)
requireUpperBoundDeps inneffective when DependencyManagement is used
Key: MENFORCER-146
URL: https://jira.codehaus.org/browse/MENFORCER-146
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Reporter: Ben Noland
Consider the following dependency tree:
{noformat}
A
+- B
| \-X (1.1)
+- C
\-X (2.1)
{noformat}
I can use the requireUpperBoundDeps to find these types of issues (I want to
use D 2.1 rather than 1.1).
To fix the issue I use dependencyManagement to set the version of X to 2.1.
As I understand it, using dependencyManagement effectively changes the tree
to look like this:
{noformat}
A
+- B
| \-X (2.1) (really 1.1, but managed to 2.1)
+- C
\-X (2.1)
{noformat}
Now, if B is upgraded to depend on X 2.5, I will never know:
{noformat}
A
+- B
| \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
+- C
\-X (2.1)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317435#comment-317435
]
Robert Scholte commented on MENFORCER-146:
--
IMO as long as B and C aren't related, it shouldn't be an issue. But I can
imagine the situation. So {{useManagedVersions}} should be a {{boolean}},
default to {{false}}. A test to prevent regression would be welcome as well.
requireUpperBoundDeps inneffective when DependencyManagement is used
Key: MENFORCER-146
URL: https://jira.codehaus.org/browse/MENFORCER-146
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Reporter: Ben Noland
Attachments: RequireUpperBoundDepsVisitor.diff
Consider the following dependency tree:
{noformat}
A
+- B
| \-X (1.1)
+- C
\-X (2.1)
{noformat}
I can use the requireUpperBoundDeps to find these types of issues (I want to
use D 2.1 rather than 1.1).
To fix the issue I use dependencyManagement to set the version of X to 2.1.
As I understand it, using dependencyManagement effectively changes the tree
to look like this:
{noformat}
A
+- B
| \-X (2.1) (really 1.1, but managed to 2.1)
+- C
\-X (2.1)
{noformat}
Now, if B is upgraded to depend on X 2.5, I will never know:
{noformat}
A
+- B
| \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
+- C
\-X (2.1)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-557) ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently)
[
https://jira.codehaus.org/browse/SCM-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-557:
---
Description:
Trying to run the release plugin for a git project
http://xircles.codehaus.org/projects/paranamer/repo/git/repo (branch real_asm).
In the prepare phase it barfs like so :
{noformat}
[INFO] [INFO]
[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO]
[INFO] [INFO] Total time: 11 seconds
[INFO] [INFO] Finished at: Thu Jun 10 05:21:23 CDT 2010
[INFO] [INFO] Final Memory: 39M/81M
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer git add --
pom.xml
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer git status
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[DEBUG] # On branch real_asm
[DEBUG] # Changes to be committed:
[DEBUG] # (use git reset HEAD file... to unstage)
[DEBUG] #
[DEBUG] # modified: pom.xml
[DEBUG] #
[DEBUG] # Untracked files:
[DEBUG] # (use git add file... to include in what will be committed)
[DEBUG] #
[DEBUG] # pom.xml.releaseBackup
[DEBUG] # release.properties
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer git commit
--verbose -F
/var/folders/qb/qbAjORvlEIKOmBNFQArSsTI/-Tmp-/maven-scm-964404670.commit
pom.xml
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer git
symbolic-ref HEAD
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO] Executing: /bin/sh -c cd /scm/oss/paranamer-git/paranamer git push
ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm
[INFO] Working directory: /scm/oss/paranamer-git/paranamer
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The git-push command failed.
Command output:
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##
ERROR:gitosis.serve.main:Arguments to command look dangerous
fatal: The remote end hung up unexpectedly
[INFO]
[DEBUG] Trace
org.apache.maven.BuildFailureException: Unable to commit files
Provider message:
The git-push command failed.
Command output:
##
Unauthorized access to this system (codehaus01) is forbidden and will
be prosecuted by law. By accessing this system, you agree that your
actions may be monitored if unauthorized usage is suspected.
##
ERROR:gitosis.serve.main:Arguments to command look dangerous
fatal: The remote end hung up unexpectedly
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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)
[jira] (SCM-552) No such command 'add' using Clearcase adaptor when performing release:prepare-with-pom
[
https://jira.codehaus.org/browse/SCM-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-552:
---
Component/s: (was: maven-plugin)
maven-scm-provider-clearcase
Description:
When preparing the release using {{release:prepare-with-pom}}, the process can
not be completed as it seems to try to add the generated {{release-pom.xml}}
into clearcase, but received an error 'No such command 'add' '
From the SCM matrix, it appears that this operation is valid. And ideally, I
do not want maven to automatically check in the generated files.
Below is the generated trace:
{noformat}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cannot add release POM to SCM: No such command 'add'.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Cannot add release POM t
o SCM: No such command 'add'.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
Goal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:284)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.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.plugin.MojoExecutionException: Cannot add release PO
M to SCM: No such command 'add'.
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
epareReleaseMojo.java:215)
at org.apache.maven.plugins.release.PrepareWithPomReleaseMojo.execute(Pr
epareWithPomReleaseMojo.java:48)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Cannot add
release POM to SCM: No such command 'add'.
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.addRel
easePomsToScm(GenerateReleasePomsPhase.java:199)
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.genera
teReleasePoms(GenerateReleasePomsPhase.java:132)
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.execut
e(GenerateReleasePomsPhase.java:105)
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.execut
e(GenerateReleasePomsPhase.java:92)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:203)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:103)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
epareReleaseMojo.java:211)
... 20 more
Caused by: org.apache.maven.scm.NoSuchCommandScmException: No such command 'add'
.
at org.apache.maven.scm.provider.AbstractScmProvider.add(AbstractScmProv
ider.java:147)
at org.apache.maven.scm.provider.AbstractScmProvider.add(AbstractScmProv
ider.java:141)
at org.apache.maven.scm.provider.AbstractScmProvider.add(AbstractScmProv
ider.java:124)
at org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.addRel
easePomsToScm(GenerateReleasePomsPhase.java:190)
... 27 more
{noformat}
Can anyone make sense of it?
was:
When preparing the
[jira] (SCM-552) No such command 'add' using Clearcase adaptor when performing release:prepare-with-pom
[
https://jira.codehaus.org/browse/SCM-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317445#comment-317445
]
Robert Scholte commented on SCM-552:
{quote}And ideally, I do not want maven to automatically check in the generated
files{quote}
In that case you should run the release-plugin with the {{prepare}}-goal.
No such command 'add' using Clearcase adaptor when performing
release:prepare-with-pom
--
Key: SCM-552
URL: https://jira.codehaus.org/browse/SCM-552
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-clearcase
Environment: Windows XP, running Clearcase 7, Java 1.6.
Reporter: Jason Lee
When preparing the release using {{release:prepare-with-pom}}, the process
can not be completed as it seems to try to add the generated
{{release-pom.xml}} into clearcase, but received an error 'No such command
'add' '
From the SCM matrix, it appears that this operation is valid. And ideally, I
do not want maven to automatically check in the generated files.
Below is the generated trace:
{noformat}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cannot add release POM to SCM: No such command 'add'.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Cannot add release
POM t
o SCM: No such command 'add'.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
Goal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.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.plugin.MojoExecutionException: Cannot add release
PO
M to SCM: No such command 'add'.
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
epareReleaseMojo.java:215)
at
org.apache.maven.plugins.release.PrepareWithPomReleaseMojo.execute(Pr
epareWithPomReleaseMojo.java:48)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Cannot
add
release POM to SCM: No such command 'add'.
at
org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.addRel
easePomsToScm(GenerateReleasePomsPhase.java:199)
at
org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.genera
teReleasePoms(GenerateReleasePomsPhase.java:132)
at
org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.execut
e(GenerateReleasePomsPhase.java:105)
at
org.apache.maven.shared.release.phase.GenerateReleasePomsPhase.execut
e(GenerateReleasePomsPhase.java:92)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:203)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:140)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:103)
[jira] (MRELEASE-821) Profiles enabled on the command line are not passed to the forked maven instance
[
https://jira.codehaus.org/browse/MRELEASE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-821.
---
Resolution: Not A Bug
Assignee: Robert Scholte
MRELEASE-571 is the issue responsible for the fix, and it has this quote:
{quote}
Be aware that this fix will only work for Maven3, because only this version has
an API to get the original passed commandline arguments.
To get the same result with Maven2 requires a lot of calculations and even then
it is not sure if all profiles are gathered.
{quote}
It is not possible to fix this for Maven2.
Profiles enabled on the command line are not passed to the forked maven
instance
Key: MRELEASE-821
URL: https://jira.codehaus.org/browse/MRELEASE-821
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.4
Reporter: Steve Ash
Assignee: Robert Scholte
Priority: Blocker
Attachments: FS-RELEASE-RELEASE-31.log
I enable some profiles on the command line, which activate our companies
repositories. I see in the maven instance that is first called they are
active.
{panel}
build 17-Jan-2013 12:40:34[INFO]
build 17-Jan-2013 12:40:34[INFO] Building fuzzy-project 1.2.1-SNAPSHOT
build 17-Jan-2013 12:40:34[INFO]
...
build 17-Jan-2013 12:40:34[DEBUG] === PROJECT BUILD PLAN
build 17-Jan-2013 12:40:34[DEBUG] Project:
com.argodata.fuzzy:fuzzy-project:1.2.1-SNAPSHOT
build 17-Jan-2013 12:40:34[DEBUG] Dependencies (collect): []
build 17-Jan-2013 12:40:34[DEBUG] Dependencies (resolve): []
build 17-Jan-2013 12:40:34[DEBUG] Repositories (dependencies): [central
(http://membuild01:8081/artifactory/libs-release, releases), snapshots
(http://membuild01:8081/artifactory/libs-snapshot, releases+snapshots),
com.argodata (http://serv107.argo.local/archiva/repository/com.argodata,
releases+snapshots)]
{panel}
When the prepare method forks a new maven instance, the profiles are not
enabled, causing our repos to not be used:
{panel}
build 17-Jan-2013 12:41:21[INFO] [INFO]
build 17-Jan-2013 12:41:21[INFO] [INFO] Building fuzzy-project 1.2.1
build 17-Jan-2013 12:41:21[INFO] [INFO]
...
build 17-Jan-2013 12:41:21[INFO] [DEBUG] === PROJECT BUILD PLAN
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Project:
com.argodata.fuzzy:fuzzy-project:1.2.1
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (collect): []
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (resolve): []
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (dependencies):
[central (http://repo1.maven.org/maven2, releases)]
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (plugins) :
[central (http://repo1.maven.org/maven2, releases)]
{panel}
We were using 2.2.1 and not getting some of our profiles passed to the forked
process, but we were getting the repos there...so I'm really confused. I
upgraded to 2.4 to fix the problem seeing that MRELEASE-260 seemed like the
culprit. When I upgraded however, it started failing sooner due to this
problem.
So I'm lost.
I've attached the whole log if you're interested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status regexps invalid
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317511#comment-317511
]
Robert Scholte commented on SCM-709:
Now we seem to have to root cause. Still weird that only a few people seem to
have trouble with it. The next question would be: which of the 2 values is
wrong?
REGRESSION: git status regexps invalid
--
Key: SCM-709
URL: https://jira.codehaus.org/browse/SCM-709
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.8, 1.8.1
Reporter: Robert Scholte
Priority: Blocker
SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
language independend.
The regular expressions have changed, but they are too wide, which might
cause invalid matches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status regexps invalid
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317514#comment-317514
]
Robert Scholte commented on SCM-709:
Differences between --short and --porcelain:
{quote}
1. The users color.status configuration is not respected; color will always be
off.
2. The users status.relativePaths configuration is not respected; paths shown
will always be relative to the repository root.
{quote}
So this is actually saying that the working directory is ignored. And if the
working directory is not the repository root, you're having an issue.
REGRESSION: git status regexps invalid
--
Key: SCM-709
URL: https://jira.codehaus.org/browse/SCM-709
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.8, 1.8.1
Reporter: Robert Scholte
Priority: Blocker
SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
language independend.
The regular expressions have changed, but they are too wide, which might
cause invalid matches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-821) Profiles enabled on the command line are not passed to the forked maven instance
[
https://jira.codehaus.org/browse/MRELEASE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317526#comment-317526
]
Robert Scholte commented on MRELEASE-821:
-
You said 2.2.1, or is this the maven-release-version?
Assuming that the profiles are listed in the {{settings.xml}}, you need to
upgrade Maven to 3.0.4, as mentioned
http://maven.apache.org/maven-release/maven-release-plugin/
Profiles enabled on the command line are not passed to the forked maven
instance
Key: MRELEASE-821
URL: https://jira.codehaus.org/browse/MRELEASE-821
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.4
Reporter: Steve Ash
Assignee: Robert Scholte
Priority: Blocker
Attachments: FS-RELEASE-RELEASE-31.log
I enable some profiles on the command line, which activate our companies
repositories. I see in the maven instance that is first called they are
active.
{panel}
build 17-Jan-2013 12:40:34[INFO]
build 17-Jan-2013 12:40:34[INFO] Building fuzzy-project 1.2.1-SNAPSHOT
build 17-Jan-2013 12:40:34[INFO]
...
build 17-Jan-2013 12:40:34[DEBUG] === PROJECT BUILD PLAN
build 17-Jan-2013 12:40:34[DEBUG] Project:
com.argodata.fuzzy:fuzzy-project:1.2.1-SNAPSHOT
build 17-Jan-2013 12:40:34[DEBUG] Dependencies (collect): []
build 17-Jan-2013 12:40:34[DEBUG] Dependencies (resolve): []
build 17-Jan-2013 12:40:34[DEBUG] Repositories (dependencies): [central
(http://membuild01:8081/artifactory/libs-release, releases), snapshots
(http://membuild01:8081/artifactory/libs-snapshot, releases+snapshots),
com.argodata (http://serv107.argo.local/archiva/repository/com.argodata,
releases+snapshots)]
{panel}
When the prepare method forks a new maven instance, the profiles are not
enabled, causing our repos to not be used:
{panel}
build 17-Jan-2013 12:41:21[INFO] [INFO]
build 17-Jan-2013 12:41:21[INFO] [INFO] Building fuzzy-project 1.2.1
build 17-Jan-2013 12:41:21[INFO] [INFO]
...
build 17-Jan-2013 12:41:21[INFO] [DEBUG] === PROJECT BUILD PLAN
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Project:
com.argodata.fuzzy:fuzzy-project:1.2.1
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (collect): []
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (resolve): []
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (dependencies):
[central (http://repo1.maven.org/maven2, releases)]
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (plugins) :
[central (http://repo1.maven.org/maven2, releases)]
{panel}
We were using 2.2.1 and not getting some of our profiles passed to the forked
process, but we were getting the repos there...so I'm really confused. I
upgraded to 2.4 to fix the problem seeing that MRELEASE-260 seemed like the
culprit. When I upgraded however, it started failing sooner due to this
problem.
So I'm lost.
I've attached the whole log if you're interested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-798) Commit additional files with release plugin
[ https://jira.codehaus.org/browse/MRELEASE-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317561#comment-317561 ] Robert Scholte commented on MRELEASE-798: - Not yet Commit additional files with release plugin --- Key: MRELEASE-798 URL: https://jira.codehaus.org/browse/MRELEASE-798 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare, scm Affects Versions: 2.3.2 Reporter: Thorsten Hoeger Hi, is there any possibility to have the release-plugin commit additional files which were generated/modified in the preparationGoals. Now only the pom.xml is commited. Using scm-plugin has some serious drawbacks in this situation. If it is not possible at the moment, is there any chance to get this in the future. Maybe there could be a parameter additionalCommitFiles with a list of files to commit along with pom.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-709:
---
Description:
SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
language independend.
Without the {{--porcelain}} option files were listed relative to the working
directory, but with {{--porcelain}} files are listed relative to the repository
root. In most cases these are the same, but not always.
was:
SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
language independend.
The regular expressions have changed, but they are too wide, which might cause
invalid matches.
Assignee: Robert Scholte
Summary: REGRESSION: git status doesn't work if repository root is not
the working directory (was: REGRESSION: git status regexps invalid)
REGRESSION: git status doesn't work if repository root is not the working
directory
---
Key: SCM-709
URL: https://jira.codehaus.org/browse/SCM-709
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.8, 1.8.1
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Blocker
SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
language independend.
Without the {{--porcelain}} option files were listed relative to the working
directory, but with {{--porcelain}} files are listed relative to the
repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317806#comment-317806
]
Robert Scholte commented on SCM-709:
My latest commit was
https://git-wip-us.apache.org/repos/asf?p=maven-scm.git;a=commitdiff;h=6aff3431817108139d29914dc81d8d2dc53e3c6a
The idea is to check for a forward slash at the end. If so, it should be a
directory, otherwise a file.
But if I switch the lines of {{private boolean isFile( String file )}}, some
tests fail.
The reason: if a file does not exist, it returns {{false}}, but that's not the
same as being a directory.
Mark Struberg offered his help within a couple of weeks to check if the tests
are wrong or not.
Or you could speed it up by having a look at it.
REGRESSION: git status doesn't work if repository root is not the working
directory
---
Key: SCM-709
URL: https://jira.codehaus.org/browse/SCM-709
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.8, 1.8.1
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Blocker
SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
language independend.
Without the {{--porcelain}} option files were listed relative to the working
directory, but with {{--porcelain}} files are listed relative to the
repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317868#comment-317868
]
Robert Scholte commented on SCM-709:
@Andrei:
1. Although it looks like a hack, this will probably work. It's either knowing
the relative path between the workingdirectory and the repository root and
check the actual file, or get the information from the status-entries. Git
claims that the output of porcelain is consistent. After a chat with Mark we
decided to try this. We have several different CI systems to verify that this
works. I would expect that the status-entry would already have enough
information to decide if the file exists or not.
2. That was another idea, but I'm pretty sure that it will break the tests
right now.
3. Probably not. As a Windows user (probably the most critical OS in this case)
I can confirm that the GIT output is consistent and uses forward slashes.
4. Do we need to check if the file exists, if we better analyze the status
output
5. See 4
6. That was my question to Mark
7. how?
@Tim
Good point. AFAIK scm status expects all modified files inside (relative to?)
the working directory.
REGRESSION: git status doesn't work if repository root is not the working
directory
---
Key: SCM-709
URL: https://jira.codehaus.org/browse/SCM-709
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.8, 1.8.1
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Blocker
SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
language independend.
Without the {{--porcelain}} option files were listed relative to the working
directory, but with {{--porcelain}} files are listed relative to the
repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317874#comment-317874
]
Robert Scholte commented on SCM-709:
SCM-686 broke it
REGRESSION: git status doesn't work if repository root is not the working
directory
---
Key: SCM-709
URL: https://jira.codehaus.org/browse/SCM-709
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.8, 1.8.1
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Blocker
SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
language independend.
Without the {{--porcelain}} option files were listed relative to the working
directory, but with {{--porcelain}} files are listed relative to the
repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-170) http://maven.apache.org/xsd/assembly-2.4.0.xsd page not found
[ https://jira.codehaus.org/browse/MNGSITE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318198#comment-318198 ] Robert Scholte commented on MNGSITE-170: That's because it does not exist. See http://maven.apache.org/plugins/maven-assembly-plugin/index.html#Assembly_and_Component_Descriptor_Schemas_XSD for all valid xsd's. Is there a page which refers to this XSD? http://maven.apache.org/xsd/assembly-2.4.0.xsd page not found - Key: MNGSITE-170 URL: https://jira.codehaus.org/browse/MNGSITE-170 Project: Maven Project Web Site Issue Type: Bug Reporter: Ronnie Downing Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ https://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318203#comment-318203 ] Robert Scholte commented on MNG-3559: - @Nicholas: the short answer is https://twitter.com/jasondillon/status/290628687202754561, the more detailed answer is http://rfscholte.wordpress.com/2010/09/05/how-to-create-a-jar-containing-reusableabstract-testclasses-with-maven/ To me this issue is more of an anti-pattern and the blog explains why: you will loose dependency management. The patch assumes a way too simple usecase. Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first -- Key: MNG-3559 URL: https://jira.codehaus.org/browse/MNG-3559 Project: Maven 2 3 Issue Type: Bug Components: Bootstrap Build Affects Versions: 2.0.8, 2.0.9 Reporter: Joshua Pollak Fix For: Issues to be reviewed for 3.x Attachments: ActiveProjectTestJar-2.0.9.patch, ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz We have project with a few sibling modules: * Project moduleA +-- /src/main/java (Common Code) +-- /src/test/java(Common Test Framework) moduleB moduleC +-- /src/main/java (Production Code, depends on moduleA Common code) +-- /src/test/java(Production Test Framework, depends on moduleA Common Test Framework) I dont think there is anything wrong with this project in concept. moduleC's main code depends son moduleA's main code, and moduleC's test code depends on moduleA's test code. This works if I run 'mvn install', but for rapid development, we often run single unit tests and need to be able to run mvn test from the top level project, which fails. For an example, download the attached project and run mvn test from the trunk directory. It will fail with the error pasted below. Then, run mvn install and everything works ok. We should be able to run our unit tests without having to install first. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT -- 1 required artifact is missing. for artifact: com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-147) RequireSamePluginVersions
Robert Scholte created MENFORCER-147: Summary: RequireSamePluginVersions Key: MENFORCER-147 URL: https://jira.codehaus.org/browse/MENFORCER-147 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Affects Versions: 1.2 Reporter: Robert Scholte When plugins are specified as both a build plugin and a reporting plugin, their versions should be the same. This way it is not required to introduce another property just to keep these versions in sync. Add several predefined plugins, which versions should match. For instance: maven-surefire-plugin, maven-failsafe-plugin, maven-surefire-report-plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-92) Upgrade Maven prerequisite to 2.2.1
Robert Scholte created MPH-92: - Summary: Upgrade Maven prerequisite to 2.2.1 Key: MPH-92 URL: https://jira.codehaus.org/browse/MPH-92 Project: Maven 2.x Help Plugin Issue Type: Task Affects Versions: 2.1.1 Reporter: Robert Scholte -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-91) No deep copy with effective-settings, causing passwords to be anonymized during further executions
[
https://jira.codehaus.org/browse/MPH-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MPH-91:
-
Assignee: Robert Scholte
No deep copy with effective-settings, causing passwords to be anonymized
during further executions
--
Key: MPH-91
URL: https://jira.codehaus.org/browse/MPH-91
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Critical
When running {{mvn help:effective-settings sql:execute}} all passwords (both
encrypted and unencrypted) are anonymized during {{help:effective-settings}},
which causes {{***}} to be passed for every password.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-91) No deep copy with effective-settings, causing passwords to be anonymized during further executions
Robert Scholte created MPH-91:
-
Summary: No deep copy with effective-settings, causing passwords
to be anonymized during further executions
Key: MPH-91
URL: https://jira.codehaus.org/browse/MPH-91
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Robert Scholte
Priority: Critical
When running {{mvn help:effective-settings sql:execute}} all passwords (both
encrypted and unencrypted) are anonymized during {{help:effective-settings}},
which causes {{***}} to be passed for every password.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-92) Upgrade Maven prerequisite to 2.2.1
[ https://jira.codehaus.org/browse/MPH-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MPH-92: - Assignee: Robert Scholte Upgrade Maven prerequisite to 2.2.1 --- Key: MPH-92 URL: https://jira.codehaus.org/browse/MPH-92 Project: Maven 2.x Help Plugin Issue Type: Task Affects Versions: 2.1.1 Reporter: Robert Scholte Assignee: Robert Scholte -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-92) Upgrade Maven prerequisite to 2.2.1
[ https://jira.codehaus.org/browse/MPH-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MPH-92. - Resolution: Fixed Fix Version/s: 2.2 Fixed in [r1440628|http://svn.apache.org/viewvc?rev=1440628view=rev] Upgrade Maven prerequisite to 2.2.1 --- Key: MPH-92 URL: https://jira.codehaus.org/browse/MPH-92 Project: Maven 2.x Help Plugin Issue Type: Task Affects Versions: 2.1.1 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 2.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-91) No deep copy with effective-settings, causing passwords to be anonymized during further executions
[
https://jira.codehaus.org/browse/MPH-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPH-91.
-
Resolution: Fixed
Fix Version/s: 2.2
Fixed in [r1440665|http://svn.apache.org/viewvc?rev=1440665view=rev]
No deep copy with effective-settings, causing passwords to be anonymized
during further executions
--
Key: MPH-91
URL: https://jira.codehaus.org/browse/MPH-91
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Critical
Fix For: 2.2
When running {{mvn help:effective-settings sql:execute}} all passwords (both
encrypted and unencrypted) are anonymized during {{help:effective-settings}},
which causes {{***}} to be passed for every password.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-93) Replace expression label with user property when possible
Robert Scholte created MPH-93:
-
Summary: Replace expression label with user property when possible
Key: MPH-93
URL: https://jira.codehaus.org/browse/MPH-93
Project: Maven 2.x Help Plugin
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Robert Scholte
Expression is the more technical label for a field which should contain exaclty
1 expression, so you can add it as a {{-Dkey=value}} on the commandline.
Plugin developers often mix default-value and expression, but with the new Mojo
Annotations this difference is much more clear by talking about {{property}}
instead of {{expression}} and removing the ${ and }.
There are still enough expressions which contain a default-value ( for instance
${project.build.directory}/generated-sources/foobar/ ), so only in case of
valid expressions the User property label should be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-93) Replace expression label with user property when possible
[
https://jira.codehaus.org/browse/MPH-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPH-93.
-
Resolution: Fixed
Fix Version/s: 2.2
Assignee: Robert Scholte
Fixed in [r1440711|http://svn.apache.org/viewvc?rev=1440711view=rev]
Replace expression label with user property when possible
-
Key: MPH-93
URL: https://jira.codehaus.org/browse/MPH-93
Project: Maven 2.x Help Plugin
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Robert Scholte
Assignee: Robert Scholte
Fix For: 2.2
Expression is the more technical label for a field which should contain
exaclty 1 expression, so you can add it as a {{-Dkey=value}} on the
commandline.
Plugin developers often mix default-value and expression, but with the new
Mojo Annotations this difference is much more clear by talking about
{{property}} instead of {{expression}} and removing the ${ and }.
There are still enough expressions which contain a default-value ( for
instance ${project.build.directory}/generated-sources/foobar/ ), so only in
case of valid expressions the User property label should be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-90) help:effective-pom does not show full effective-pom
[
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPH-90.
-
Resolution: Cannot Reproduce
Assignee: Robert Scholte
Added an IT in [r1440722|http://svn.apache.org/viewvc?rev=1440722view=rev]
Tested it with M3.0.4, M3.0.3 and M2.2.1 but couldn't reproduce it.
help:effective-pom does not show full effective-pom
---
Key: MPH-90
URL: https://jira.codehaus.org/browse/MPH-90
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Maven 2.2.1 and Maven 3.0.3
Reporter: Michael Osipov
Assignee: Robert Scholte
When I define something like this in my POM:
{code:xml}
properties
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
/properties
{code}
the compiler plugin picks this up but this settings is not reflected in the
{{Model}} and not written out as part of the effective POM.
Either this is fixed within the system or the docs of this plugin need to
mention this clearly.
This is related to MJAVADOC-310 and MPIR-263.
I a workaround for now by passing those properties to the plugin but this
does not solve this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318391#comment-318391
]
Robert Scholte commented on MINSTALL-94:
Assuming you're using a Artifact Repository Manager, you should use {{verify}}
instead of {{install}} and let Jenkins deploy the artifacts when the job has
ended succesfully.
And what's wrong with the
[skip|http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html#skip]-parameter?
Optional: limit install to packaging x and or make install plugin not fail if
no artifacts were created for some modules.
-
Key: MINSTALL-94
URL: https://jira.codehaus.org/browse/MINSTALL-94
Project: Maven 2.x Install Plugin
Issue Type: Improvement
Reporter: Henning Gross
Attachments: MINSTALL-94.patch
Background: I am working in a huge project with a lot of modules having a lot
of javascript-optimization and stuff happening in lifecycle-steps after
compile. This results in bad performance on jenkins. I would like to run
mvn compile install:install as I only need the jars/libs to be installed and
not the wars (and more important I do not need them to be built).
Please introduce Parameters like
doNotInstallwar/doNotInstall
or
failIfNoArtifactfalse...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-186) FileTabCharacter check not working
[
https://jira.codehaus.org/browse/MCHECKSTYLE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCHECKSTYLE-186:
---
Description:
The FileTabCharacter check doesnt seem to work. Below is my config:
{code:xml}
module name=Checker
..
..
!-- No TAB characters in the source code --
module name=FileTabCharacter
property name=eachLine value=true /
property name=fileExtensions value=java,xml /
/module
..
..
module name=TreeWalker
..
..
/module
/module
{code}
I have my xml files - pom.xml and checkstyle config xml containing tabs but
none of them are flagged as violations.
Some additional info - my plugin config looks like this:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.9.1/version
executions
execution
phaseverify/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration
configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation
suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
/configuration
/plugin
{code}
was:
The FileTabCharacter check doesnt seem to work. Below is my config:
module name=Checker
..
..
!-- No TAB characters in the source code --
module name=FileTabCharacter
property name=eachLine value=true /
property name=fileExtensions value=java,xml /
/module
..
..
module name=TreeWalker
..
..
/module
/module
I have my xml files - pom.xml and checkstyle config xml containing tabs but
none of them are flagged as violations.
Some additional info - my plugin config looks like this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.9.1/version
executions
execution
phaseverify/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration
configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation
suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
/configuration
/plugin
FileTabCharacter check not working
--
Key: MCHECKSTYLE-186
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-186
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Reporter: Dipti Desai
Priority: Minor
The FileTabCharacter check doesnt seem to work. Below is my config:
{code:xml}
module name=Checker
..
..
!-- No TAB characters in the source code --
module name=FileTabCharacter
property name=eachLine value=true /
property name=fileExtensions value=java,xml /
/module
..
..
module name=TreeWalker
..
..
/module
/module
{code}
I have my xml files - pom.xml and checkstyle config xml containing tabs but
none of them are flagged as violations.
Some additional info - my plugin config looks like this:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.9.1/version
executions
execution
phaseverify/phase
goals
goalcheck/goal
/goals
/execution
/executions
configuration
configLocationcheckstyle/kepler-checkstyle-config.xml/configLocation
suppressionsLocation${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml/suppressionsLocation
/configuration
/plugin
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-90) help:effective-pom does not show full effective-pom
[
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318410#comment-318410
]
Robert Scholte commented on MPH-90:
---
No problem that it is reopened.
I'm not interested in what the debugger is saying halfway the execution, but
I'm more interested in what kind of output you would expect. Please check out
this project and run {{mvn clean verify -Prun-its
-Dinvoker.test=effective-pom_properties}} and have a look at the
{{target/it/effective-pom_properties/build.log}}.
If you change the {{invoker.goals}} to {{compile}} you'll see something like
{noformat}
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile from plugin realm
ClassRealm[pluginorg.apache.maven.plugins:maven-compiler-plugin:2.3.2, parent:
sun.misc.Launcher$AppClassLoader@5acac268]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
configurator --
[DEBUG] (f) basedir =
E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties
[DEBUG] (f) buildDirectory =
E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\target
[DEBUG] (f) classpathElements =
[E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\target\classes]
[DEBUG] (f) compileSourceRoots =
[E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\src\main\java]
[DEBUG] (f) compilerId = javac
[DEBUG] (f) debug = true
[DEBUG] (f) failOnError = true
[DEBUG] (f) fork = false
[DEBUG] (f) generatedSourcesDirectory =
E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\target\generated-sources\annotations
[DEBUG] (f) optimize = false
[DEBUG] (f) outputDirectory =
E:\java-workspace\apache-maven-plugins\maven-help-plugin\target\it\effective-pom_properties\target\classes
[DEBUG] (f) outputFileName = mph-90-1.0-SNAPSHOT
[DEBUG] (f) projectArtifact =
org.apache.maven.its.help:mph-90:jar:1.0-SNAPSHOT
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@2bbd9de3
[DEBUG] (f) showDeprecation = false
[DEBUG] (f) showWarnings = false
[DEBUG] (f) source = 1.6
[DEBUG] (f) staleMillis = 0
[DEBUG] (f) target = 1.6
[DEBUG] (f) verbose = false
[DEBUG] -- end configuration --
{noformat}
IMO {{effective-pom}} is not about the build-plan and build-configuration, but
only about merging the current pom with all its parent up to the super-pom
provided by Maven.
help:effective-pom does not show full effective-pom
---
Key: MPH-90
URL: https://jira.codehaus.org/browse/MPH-90
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Maven 2.2.1 and Maven 3.0.3
Reporter: Michael Osipov
Assignee: Robert Scholte
Attachments: compiler-debug.png, effective-pom.log, pom.xml,
target-option.png
When I define something like this in my POM:
{code:xml}
properties
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
/properties
{code}
the compiler plugin picks this up but this settings is not reflected in the
{{Model}} and not written out as part of the effective POM.
Either this is fixed within the system or the docs of this plugin need to
mention this clearly.
This is related to MJAVADOC-310 and MPIR-263.
I a workaround for now by passing those properties to the plugin but this
does not solve this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-90) help:effective-pom does not show full effective-pom
[
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318412#comment-318412
]
Robert Scholte commented on MPH-90:
---
What kind of desciption would you suggest? Is the word 'effective' confusing?
The {{effective-pom}} is a standalone pom.xml, where all parents are merged
into. Notice that it doesn't refer to a parent anymore.
help:effective-pom does not show full effective-pom
---
Key: MPH-90
URL: https://jira.codehaus.org/browse/MPH-90
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Maven 2.2.1 and Maven 3.0.3
Reporter: Michael Osipov
Assignee: Robert Scholte
Attachments: compiler-debug.png, effective-pom.log, pom.xml,
target-option.png
When I define something like this in my POM:
{code:xml}
properties
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
/properties
{code}
the compiler plugin picks this up but this settings is not reflected in the
{{Model}} and not written out as part of the effective POM.
Either this is fixed within the system or the docs of this plugin need to
mention this clearly.
This is related to MJAVADOC-310 and MPIR-263.
I a workaround for now by passing those properties to the plugin but this
does not solve this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318481#comment-318481
]
Robert Scholte commented on MINSTALL-94:
What I don't like about the {{failIf}} option, is that when an artifact should
have been available the build should break, but by defining this option these
build-failures are ignored. So the best way would be to define it per module,
making it equivalent to the skip-parameter.
AFAIK you need to run {{package}} in order to run {{install}} or {{deploy}},
because that's when the jar/war/ear is bound to the {{MavenProject}}, so the
next goals know what to install or deploy.
If you want to confirm that the whole multimodule can be compiled, {{mvn
compile}} is enough with Maven3. For inner-multimodule dependencies the
classes-directory will be used instead of the jar.
Have you thought about the evil options {{maven.test.skip}} and {{skipTests}}?
Optional: limit install to packaging x and or make install plugin not fail if
no artifacts were created for some modules.
-
Key: MINSTALL-94
URL: https://jira.codehaus.org/browse/MINSTALL-94
Project: Maven 2.x Install Plugin
Issue Type: Improvement
Reporter: Henning Gross
Attachments: MINSTALL-94.patch
Background: I am working in a huge project with a lot of modules having a lot
of javascript-optimization and stuff happening in lifecycle-steps after
compile. This results in bad performance on jenkins. I would like to run
mvn compile install:install as I only need the jars/libs to be installed and
not the wars (and more important I do not need them to be built).
Please introduce Parameters like
doNotInstallwar/doNotInstall
or
failIfNoArtifactfalse...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MINSTALL-94.
--
Resolution: Won't Fix
Assignee: Robert Scholte
If you take a good look at the message, you should see that Maven is looking
for
{{MINSTALL-94:mi94-some-commons-module:jar:1.0-SNAPSHOT}}, but that project has
packaging-type {{pom}}, so no wonder it wasn't found. Removing the packaging
type makes the build succeed.
Optional: limit install to packaging x and or make install plugin not fail if
no artifacts were created for some modules.
-
Key: MINSTALL-94
URL: https://jira.codehaus.org/browse/MINSTALL-94
Project: Maven 2.x Install Plugin
Issue Type: Improvement
Reporter: Henning Gross
Assignee: Robert Scholte
Attachments: MINSTALL-94.patch, MINSTALL-94.zip, MINSTALL-94.zip
Background: I am working in a huge project with a lot of modules having a lot
of javascript-optimization and stuff happening in lifecycle-steps after
compile. This results in bad performance on jenkins. I would like to run
mvn compile install:install as I only need the jars/libs to be installed and
not the wars (and more important I do not need them to be built).
Please introduce Parameters like
doNotInstallwar/doNotInstall
or
failIfNoArtifactfalse...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-78) install:install should remove leftovers from local repository
[
https://jira.codehaus.org/browse/MINSTALL-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MINSTALL-78.
--
Resolution: Won't Fix
Assignee: Robert Scholte
I'd say this can be achieved with
[dependency:purge-local-repository|http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html].
install:install should remove leftovers from local repository
-
Key: MINSTALL-78
URL: https://jira.codehaus.org/browse/MINSTALL-78
Project: Maven 2.x Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.3.1
Reporter: Petr Kozelka
Assignee: Robert Scholte
Attachments: pom.xml
It sometimes happens that we need to change the set of output artifacts. When
this happens, the install mojo does not bother to remove older artifacts that
are no longer produced by this module.
The bad effect is, that other modules depending on the obsolete artifacts can
still use it - and later there comes a surprise.
Much better behavior in this situation would be, to remove the obsolete files
from the local repository's directory dedicated for given module.
h4. reproducing the problem
# download the sample pom to an empty directory
# execute {{mvn clean install -Dc=obsolete-demo}} - this represents the
older version of a module
# execute {{mvn clean install}} - this represents the newer version of a
module, after changing the classifier
# now, look in the local repo using {{ls -1
$HOME/.m2/repository/demo/sample-zip-module/1-SNAPSHOT}} - you will see this:
{quote}
maven-metadata-local.xml
sample-zip-module-1-SNAPSHOT-demo.zip
{color:red}sample-zip-module-1-SNAPSHOT-obsolete-demo.zip{color}
sample-zip-module-1-SNAPSHOT.pom
{quote}
h4. possible solutions
I see two approaches
# *drop the installdir first* - straightforward
# *list installdir, install, drop leftovers* - slightly more complicated but
maximizes the time of installed module existence (if that matters)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-90) help:effective-pom does not show full effective-pom
[
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPH-90.
-
Resolution: Not A Bug
Closing it because of invalid expectations.
Going back to the reason why this issue was filed: the effective-pom won't fix
MJAVADOC-310 or MPIR-263.
help:effective-pom does not show full effective-pom
---
Key: MPH-90
URL: https://jira.codehaus.org/browse/MPH-90
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Maven 2.2.1 and Maven 3.0.3
Reporter: Michael Osipov
Assignee: Robert Scholte
Attachments: compiler-debug.png, effective-pom.log, pom.xml,
target-option.png
When I define something like this in my POM:
{code:xml}
properties
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
/properties
{code}
the compiler plugin picks this up but this settings is not reflected in the
{{Model}} and not written out as part of the effective POM.
Either this is fixed within the system or the docs of this plugin need to
mention this clearly.
This is related to MJAVADOC-310 and MPIR-263.
I a workaround for now by passing those properties to the plugin but this
does not solve this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5127) CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
[
https://jira.codehaus.org/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5127:
Description:
The goal is to activate a maven profile based on OS user name.
When I create a standalone project with a profile activation, it works,
however, when I define the profile in a parent pom, it is never activated.
this works:
{code:xml}
...
profile
idTONY/id
activation
property
nameuser.name/name
valueWINTONY/value
/property
/activation
properties
/properties
{code}
So in this case, my profile is activated based on my OS user name
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building Proj1
[INFO] task-segment: [help:active-profiles] (aggregator-style)
[INFO]
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2':
The following profiles are active:
- TONY (source: pom)
{noformat}
--
However, if I now have the profiles definition in the parent pom, it doesn't
work when I build a child project
So the child project references the parent pom containing the profiles and the
activation, but when it is built,
the profile is not activated
{code:xml|title=PARENT POM}
...
profiles
profile
idTONY/id
activation
property
nameuser.name/name
valueWINTONY/value
/property
/activation
properties
...
{code}
{code:xml|title=CHILD POM (the one being built)}
project
parent
groupIdcom.capgemini.be.proj1/groupId
artifactIdparent/artifactId
version4.0.2/version
/parent
{code}
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building Proj1 Application
[INFO] task-segment: [help:active-profiles] (aggregator-style)
[INFO]
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2':
There are no active profiles.
{noformat}
was:
The goal is to activate a maven profile based on OS user name.
When I create a standalone project with a profile activation, it works,
however, when I define the profile in a parent pom, it is never activated.
this works:
...
profile
idTONY/id
activation
property
nameuser.name/name
valueWINTONY/value
/property
/activation
properties
/properties
So in this case, my profile is activated based on my OS user name
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building Proj1
[INFO] task-segment: [help:active-profiles] (aggregator-style)
[INFO]
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2':
The following profiles are active:
- TONY (source: pom)
--
However, if I now have the profiles definition in the parent pom, it doesn't
work when I build a child project
So the child project references the parent pom containing the profiles and the
activation, but when it is built,
the profile is not activated
PARENT POM:
...
profiles
profile
idTONY/id
activation
property
nameuser.name/name
valueWINTONY/value
/property
/activation
properties
...
CHILD POM (the one being built)
project
parent
groupIdcom.capgemini.be.proj1/groupId
artifactIdparent/artifactId
version4.0.2/version
/parent
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building Proj1 Application
[INFO] task-segment: [help:active-profiles] (aggregator-style)
[INFO]
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2':
There are no active profiles.
CLONE - Maven profile activation does not work when profile is defined in
inherited 'parent' pom
Key: MNG-5127
URL: https://jira.codehaus.org/browse/MNG-5127
Project: Maven 2 3
Issue Type: Bug
Reporter: Gilles Scokart
Assignee: John Casey
Attachments: daddy2.zip, daddy.zip
The goal is to activate a maven profile based on OS user name.
When I create a standalone project with a profile activation, it works,
however, when
[jira] (MPH-86) Hide passwords for effective-pom
[
https://jira.codehaus.org/browse/MPH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-86:
--
Description:
Executing
{{mvn help:effective-pom -Doutput=pom-effective.txt}}
with
{code:xml}
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
/profile
/profiles
/settings
{code}
in
{{%userprofile%\.m2\settings.xml}}
results in an pom-effective.txt
which contains
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
{code}
As (in our case) the pom-effective.txt should be checked in version control
system for later debug support we strongly need to hide the password analog to
MPH-44 Hide passwords for effective-settings:
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.password***/maven.scm.password
/properties
{code}
was:
Executing
mvn help:effective-pom -Doutput=pom-effective.txt
with
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
/profile
/profiles
/settings
in
%userprofile%\.m2\settings.xml
results in an pom-effective.txt
which contains
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
As (in our case) the pom-effective.txt should be checked in version control
system for later debug support we strongly need to hide the password analog to
MPH-44 Hide passwords for effective-settings:
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.password***/maven.scm.password
/properties
Hide passwords for effective-pom
Key: MPH-86
URL: https://jira.codehaus.org/browse/MPH-86
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files (x86)\RscApplications\Maven3\bin\..
Java version: 1.6.0, vendor: IBM Corporation
Java home: C:\programs\ejbdeploy_base_v7\java\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7, version: 6.1 build 7601 service pack 1, arch: x86,
family: windows
Reporter: Stefan Cordes
Executing
{{mvn help:effective-pom -Doutput=pom-effective.txt}}
with
{code:xml}
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
/profile
/profiles
/settings
{code}
in
{{%userprofile%\.m2\settings.xml}}
results in an pom-effective.txt
which contains
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
{code}
As (in our case) the pom-effective.txt should be checked in version control
system for later debug support we strongly need to hide the password analog
to
MPH-44 Hide passwords for effective-settings:
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.password***/maven.scm.password
/properties
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-86) Hide passwords for effective-pom
[
https://jira.codehaus.org/browse/MPH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318539#comment-318539
]
Robert Scholte commented on MPH-86:
---
The difference between the {{Settings}} and {{MavenProject}} is that for
Settings we know which fields contain a password. For a pom it is either a
property or a configuration-field.
For configuration there might be a solution if a plugin developer could specify
which field values should be hidden. That option is not there and could be
quite complex.
For properties I don't see a solution. I don't want to add some magic basic on
a naming convention.
The best solution is to use {{server}}-entries in the {{settings.xml}}. Both
the {{maven-scm-plugin}} and {{maven-release-plugin}} are capable to get the
username+password based on a server id, so you can even encrypt your password.
Hide passwords for effective-pom
Key: MPH-86
URL: https://jira.codehaus.org/browse/MPH-86
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files (x86)\RscApplications\Maven3\bin\..
Java version: 1.6.0, vendor: IBM Corporation
Java home: C:\programs\ejbdeploy_base_v7\java\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7, version: 6.1 build 7601 service pack 1, arch: x86,
family: windows
Reporter: Stefan Cordes
Executing
{{mvn help:effective-pom -Doutput=pom-effective.txt}}
with
{code:xml}
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
/profile
/profiles
/settings
{code}
in
{{%userprofile%\.m2\settings.xml}}
results in an pom-effective.txt
which contains
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
{code}
As (in our case) the pom-effective.txt should be checked in version control
system for later debug support we strongly need to hide the password analog
to
MPH-44 Hide passwords for effective-settings:
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.password***/maven.scm.password
/properties
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5036) Settings.getProfiles() returning an empty list
[ https://jira.codehaus.org/browse/MNG-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-5036. --- Resolution: Duplicate Assignee: Robert Scholte Settings.getProfiles() returning an empty list -- Key: MNG-5036 URL: https://jira.codehaus.org/browse/MNG-5036 Project: Maven 2 3 Issue Type: Bug Components: Profiles, Settings Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /opt/maven/apache-maven-3.0.3 Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: fr_FR, platform encoding: UTF-8 OS name: linux, version: 2.6.35-27-generic, arch: amd64, family: unix Reporter: Julien Nicoulaud Assignee: Robert Scholte This is related to MPH-82: in the help:all-profiles goal, [Settings.getProfiles()|http://maven.apache.org/plugins/maven-help-plugin/xref/org/apache/maven/plugins/help/AllProfilesMojo.html#317] returns an empty list since Maven 3.0. Strangely, it works fine when run with mvnDebug (without breakpoint). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-82) all-profiles does not show inactive profiles from settings file
[
https://jira.codehaus.org/browse/MPH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPH-82.
-
Resolution: Not A Bug
Assignee: Robert Scholte
This is not a bug in the {{maven-help-plugin}}, but in Maven Core. This has
been fixed with version 3.0.4
all-profiles does not show inactive profiles from settings file
---
Key: MPH-82
URL: https://jira.codehaus.org/browse/MPH-82
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Julien Nicoulaud
Assignee: Robert Scholte
The all-profiles goal does not lists the inactive profile from settings.xml.
Only the active ones are included in the list.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-90) help:effective-pom does show properties injected into plugin parameters
[
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-90:
--
Component/s: effective-pom
help:effective-pom does show properties injected into plugin parameters
---
Key: MPH-90
URL: https://jira.codehaus.org/browse/MPH-90
Project: Maven 2.x Help Plugin
Issue Type: New Feature
Components: effective-pom
Affects Versions: 2.1.1
Environment: Maven 2.2.1 and Maven 3.0.3
Reporter: Michael Osipov
Assignee: Robert Scholte
Priority: Minor
Attachments: compiler-debug.png, effective-pom.log, pom.xml,
target-option.png
When I define something like this in my POM:
{code:xml}
properties
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
/properties
{code}
the compiler plugin picks this up but this settings is not reflected in the
{{Model}} and not written out as part of the effective POM.
Either this is fixed within the system or the docs of this plugin need to
mention this clearly.
This is related to MJAVADOC-310 and MPIR-263.
I a workaround for now by passing those properties to the plugin but this
does not solve this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-85) effective-pom should resolve properties in submodules
[
https://jira.codehaus.org/browse/MPH-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-85:
--
Component/s: effective-pom
effective-pom should resolve properties in submodules
-
Key: MPH-85
URL: https://jira.codehaus.org/browse/MPH-85
Project: Maven 2.x Help Plugin
Issue Type: Improvement
Components: effective-pom
Affects Versions: 2.1.1
Environment: mvn --version
Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 14:58:54+0100)
Maven home: /usr/local/Cellar/maven/current/libexec
Java version: 1.6.0_29, vendor: Apple Inc.
Java home:
/Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac
Reporter: Mirko Friedenhagen
Attachments: mfriedenhagen-multi-module-sample-6d3b71a.zip
When defining the {{scm}} in the parent and referencing it in the
module projects I would expect {{help:effective-pom}} to resolve these.
Right now running {{{mvn clean install site site:stage}}} is resolving
this IMO correctly as specified in {{source-repository.html}}
while in the the output of {{help:effective-pom}} leaves the properties alone.
I have assembled a small multi-module project to show the effect.
Run
{code}
mvn clean install site site:stage
mvn help:effective-pom -Doutput=target/ep.xml
{code}
The original code may be seen at
https://github.com/mfriedenhagen/multi-module-sample/tree/help-effective-pom
This is maybe somewhat related to MPIR-234.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5429) REGRESSION: Injected Settings in a Mojo are missing the proxies from settings.xml
Robert Scholte created MNG-5429:
---
Summary: REGRESSION: Injected Settings in a Mojo are missing the
proxies from settings.xml
Key: MNG-5429
URL: https://jira.codehaus.org/browse/MNG-5429
Project: Maven 2 3
Issue Type: Bug
Components: Settings
Affects Versions: 3.0.4, 3.0.3, 3.0.2, 3.0.1
Reporter: Robert Scholte
If you have a Mojo with
{code}
/**
* @parameter expression=${settings}
* @required
* @readonly
*/
private Settings settings;
{code}
In Maven 2.2.1, the Settings included all the profiles, in Maven3 the proxies
are all missing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5429) REGRESSION: Injected Settings in a Mojo are missing the proxies from settings.xml
[
https://jira.codehaus.org/browse/MNG-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318597#comment-318597
]
Robert Scholte commented on MNG-5429:
-
To be precise: it is missing all inactive proxies. IMO these should still be
part of the (effective-)settings.
REGRESSION: Injected Settings in a Mojo are missing the proxies from
settings.xml
--
Key: MNG-5429
URL: https://jira.codehaus.org/browse/MNG-5429
Project: Maven 2 3
Issue Type: Bug
Components: Settings
Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4
Reporter: Robert Scholte
If you have a Mojo with
{code}
/**
* @parameter expression=${settings}
* @required
* @readonly
*/
private Settings settings;
{code}
In Maven 2.2.1, the Settings included all the profiles, in Maven3 the proxies
are all missing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-31) medium mode should include plugin descriptions
[ https://jira.codehaus.org/browse/MPH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-31: -- Component/s: describe medium mode should include plugin descriptions -- Key: MPH-31 URL: https://jira.codehaus.org/browse/MPH-31 Project: Maven 2.x Help Plugin Issue Type: Bug Components: describe Reporter: Dan Fabulich Fix For: Backlog Run mvn help:describe -Dplugin=compiler -Dmojo=compile. You'll get this: [INFO] Mojo: 'compiler:compile' === Goal: 'compile' Description: Compiles application sources === Try again with mvn help:describe -Dplugin=compiler -Dmojo=compile -Dmedium. You'll get the exact same information. Try again with -Dfull. You'll get a highly verbose description of every parameter, including their type, required, readonly, and description. -Dmedium should include an in-between amount of information. I might suggest that it include all parameters by name and the description, but not type/required/readonly. (Perhaps omit readonly parameters from -Dmedium view?) We might also consider using only the first sentence of the description, just like Javadoc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-45) Active profiles repeated each time for all projects in reactor
[ https://jira.codehaus.org/browse/MPH-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-45: -- Component/s: all-profiles Active profiles repeated each time for all projects in reactor -- Key: MPH-45 URL: https://jira.codehaus.org/browse/MPH-45 Project: Maven 2.x Help Plugin Issue Type: Improvement Components: all-profiles Reporter: Sander Verhagen Attachments: MPH-45.diff Running the active-profiles goal in a multi-module project (with subsequently more than one project in the reactor) will all the active profiles for all the projects in the reactor, repeating this for every single project that is built, resulting in exhaustive output. Given that each showing of active profiles of a single project costs about eight lines in output (including some whitelines; that's with only one profile active), and us (over here) having 73 projects in the reactor, that's (73-1)*(73-1)*8 output lines being wasted. That's a silly 41472 lines for a simple mvn install. Well, I suppose an even simpler mvn clean will do the same ;-) And now I'm not even getting started about the fact that these 73 projects all share the same profile that they get from their top parent project. Over here we have a custom maven-help-plugin version running that shows the active profiles of every project in the reactor *only once*. I made the assumption that profiles are not going to change during the coarse of a single Maven execution. Is this a patch that we would be generally interested in? Or is this perhaps a bug in the inheritence behaviour of the plugin? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-78) effective-pom creates invalid xml because it outputs the Resource.mergeId
[
https://jira.codehaus.org/browse/MPH-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-78:
--
Component/s: effective-pom
effective-pom creates invalid xml because it outputs the Resource.mergeId
-
Key: MPH-78
URL: https://jira.codehaus.org/browse/MPH-78
Project: Maven 2.x Help Plugin
Issue Type: Bug
Components: effective-pom
Affects Versions: 2.1.1
Reporter: Jacob Robertson
Priority: Minor
My organization would like to use the output from the effective-pom goal as
part of the deployed meta data in an ear. This is useful for some of our
scripting that needs properties and dependencyManagement versions resolved
(i.e. from parent poms), and the pom that is currently put in the ear does
not have that information. However, once we start generating the
effective-pom.xml file, any tool that uses xml validation will notice that
the mergeId tag is invalid. This is especially annoying in eclipse, as it
marks the whole project as having an error due to the effective-pom.xml file
being in the target directory under the eclipse project. We can of course
turn the xml validation off for the eclipse project or folder, but this is
one additional step to ask a multitude of developers to take in configuring
their projects.
I notice that the EffectivePomMojo class has a cleanModel method that
appears to sort the properties. Just to play with this, I added a
cleanResources method that calls Resource.setMergeId(null). This technique
does in fact work as I hoped for outputting the xml without the mergeId, but
it requires upgrading this plugin to use at least Maven 2.0.10.
{code}
private static void cleanModel( Model pom )
{
Properties properties = new SortedProperties();
properties.putAll( pom.getProperties() );
pom.setProperties( properties );
cleanResources( pom.getBuild().getResources() );
cleanResources( pom.getBuild().getTestResources() );
}
private static void cleanResources( List resources )
{
for ( Iterator i = resources.iterator(); i.hasNext(); )
{
Resource resource = (Resource) i.next();
resource.setMergeId( null );
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-86) Hide passwords for effective-pom
[
https://jira.codehaus.org/browse/MPH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-86:
--
Component/s: effective-pom
Hide passwords for effective-pom
Key: MPH-86
URL: https://jira.codehaus.org/browse/MPH-86
Project: Maven 2.x Help Plugin
Issue Type: Bug
Components: effective-pom
Affects Versions: 2.1.1
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files (x86)\RscApplications\Maven3\bin\..
Java version: 1.6.0, vendor: IBM Corporation
Java home: C:\programs\ejbdeploy_base_v7\java\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7, version: 6.1 build 7601 service pack 1, arch: x86,
family: windows
Reporter: Stefan Cordes
Executing
{{mvn help:effective-pom -Doutput=pom-effective.txt}}
with
{code:xml}
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
/profile
/profiles
/settings
{code}
in
{{%userprofile%\.m2\settings.xml}}
results in an pom-effective.txt
which contains
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
{code}
As (in our case) the pom-effective.txt should be checked in version control
system for later debug support we strongly need to hide the password analog
to
MPH-44 Hide passwords for effective-settings:
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.password***/maven.scm.password
/properties
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-83) all-profiles should list profiles from settings.xml even if there is no project
[ https://jira.codehaus.org/browse/MPH-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-83: -- Component/s: all-profiles all-profiles should list profiles from settings.xml even if there is no project --- Key: MPH-83 URL: https://jira.codehaus.org/browse/MPH-83 Project: Maven 2.x Help Plugin Issue Type: Bug Components: all-profiles Affects Versions: 2.1.1 Reporter: Julien Nicoulaud Running the goal all-profiles somewhere outside of a project answers No profile detected !. I have active and inactive profiles in my settings.xml, they should appear. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-53) mvn help:describe returns the version that is specified in metadata instead of the one in the parent pom
[
https://jira.codehaus.org/browse/MPH-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-53:
--
Component/s: describe
Description:
{{mvn help:describe}} returns a different version than {{mvn
help:effective-pom}} returns:
{noformat}
mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
{noformat}
However, when I run {{mvn help:effective-pom}}
I get
{code:xml}
...
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testFailureIgnoretrue/testFailureIgnore
includes
include**/*Test.java/include
/includes
formathtml/format
/configuration
/plugin
/plugins
/pluginManagement
...
{code}
My pom structure is quite simple: just a parent {{pom.xml}} with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
was:
mvn help:describe returns a different version than mvn help:effective-pom
returns:
mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
However, when I run:
mvn help:effective-pom
I get
...
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testFailureIgnoretrue/testFailureIgnore
includes
include**/*Test.java/include
/includes
formathtml/format
/configuration
/plugin
/plugins
/pluginManagement
...
My pom structure is quite simple: just a parent pom.xml with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
mvn help:describe returns the version that is specified in metadata instead
of the one in the parent pom
-
Key: MPH-53
URL: https://jira.codehaus.org/browse/MPH-53
Project: Maven 2.x Help Plugin
Issue Type: Bug
Components: describe
Affects Versions: 2.0.1
Environment: windows xp
tested with mvn 2.0.8 2.0.9
Reporter: Rintcius Blok
Fix For: Backlog
{{mvn help:describe}} returns a different version than {{mvn
help:effective-pom}} returns:
{noformat}
mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
{noformat}
However, when I run {{mvn help:effective-pom}}
I get
{code:xml}
...
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testFailureIgnoretrue/testFailureIgnore
includes
include**/*Test.java/include
/includes
formathtml/format
/configuration
/plugin
/plugins
/pluginManagement
...
{code}
My pom structure is quite simple: just a parent {{pom.xml}} with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5429) REGRESSION: Injected Settings in a Mojo are missing the proxies from settings.xml
[
https://jira.codehaus.org/browse/MNG-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318818#comment-318818
]
Robert Scholte commented on MNG-5429:
-
The problem seems to be in the
{{org.apache.maven.execution.DefaultMavenExecutionRequestPopulator}}
{code}
for ( Proxy proxy : settings.getProxies() )
{
if ( !proxy.isActive() )
{
continue;
}
proxy = proxy.clone();
request.addProxy( proxy );
}
{code}
This filtering seems to be done too early.
REGRESSION: Injected Settings in a Mojo are missing the proxies from
settings.xml
--
Key: MNG-5429
URL: https://jira.codehaus.org/browse/MNG-5429
Project: Maven 2 3
Issue Type: Bug
Components: Settings
Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4
Reporter: Robert Scholte
If you have a Mojo with
{code}
/**
* @parameter expression=${settings}
* @required
* @readonly
*/
private Settings settings;
{code}
In Maven 2.2.1, the Settings included all the profiles, in Maven3 the proxies
are all missing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-170) http://maven.apache.org/xsd/assembly-2.4.0.xsd page not found
[ https://jira.codehaus.org/browse/MNGSITE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNGSITE-170. -- Resolution: Not A Bug Assignee: Robert Scholte Closing it, as it is not a valid version. Most recent version is http://maven.apache.org/xsd/assembly-1.1.2.xsd http://maven.apache.org/xsd/assembly-2.4.0.xsd page not found - Key: MNGSITE-170 URL: https://jira.codehaus.org/browse/MNGSITE-170 Project: Maven Project Web Site Issue Type: Bug Reporter: Ronnie Downing Assignee: Robert Scholte Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-706) prepare-with-pom deletes release-pom.xml then tries to git add it (presumably so the next commit records the fact)
[ https://jira.codehaus.org/browse/SCM-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned SCM-706: -- Assignee: Mark Struberg prepare-with-pom deletes release-pom.xml then tries to git add it (presumably so the next commit records the fact) -- Key: SCM-706 URL: https://jira.codehaus.org/browse/SCM-706 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.8.1 Reporter: Darryl L. Miles Assignee: Mark Struberg Attachments: 0001-MRELEASE-809-Use-git-correctly-when-removing-and-add.patch When running: git release:prepare-with-pom After the tag is created and pushed, it then runs the sequence: git rm release-pom.xml git add -- pom.xml release-pom.xml But the git add fails because the git rm did the action of removing the actual file and adding the file removal fact to the cached index ready for the next commit to pickup. The solution is to remove the release-pom.xml argument from the git add it is unnecessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-86) Hide passwords for effective-pom
[
https://jira.codehaus.org/browse/MPH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-86:
--
Issue Type: Wish (was: Bug)
Hide passwords for effective-pom
Key: MPH-86
URL: https://jira.codehaus.org/browse/MPH-86
Project: Maven 2.x Help Plugin
Issue Type: Wish
Components: effective-pom
Affects Versions: 2.1.1
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files (x86)\RscApplications\Maven3\bin\..
Java version: 1.6.0, vendor: IBM Corporation
Java home: C:\programs\ejbdeploy_base_v7\java\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7, version: 6.1 build 7601 service pack 1, arch: x86,
family: windows
Reporter: Stefan Cordes
Executing
{{mvn help:effective-pom -Doutput=pom-effective.txt}}
with
{code:xml}
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
/profile
/profiles
/settings
{code}
in
{{%userprofile%\.m2\settings.xml}}
results in an pom-effective.txt
which contains
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.passwordMyVerySecretPassword/maven.scm.password
/properties
{code}
As (in our case) the pom-effective.txt should be checked in version control
system for later debug support we strongly need to hide the password analog
to
MPH-44 Hide passwords for effective-settings:
{code:xml}
properties
maven.scm.usernameMyUserId/maven.scm.username
maven.scm.password***/maven.scm.password
/properties
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-822) Could not release project due to Mercurial clone error when working in sub-directory
[ https://jira.codehaus.org/browse/MRELEASE-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-822: Component/s: Mercurial Affects Version/s: 2.3.2 Could not release project due to Mercurial clone error when working in sub-directory Key: MRELEASE-822 URL: https://jira.codehaus.org/browse/MRELEASE-822 Project: Maven 2.x Release Plugin Issue Type: Bug Components: Mercurial Affects Versions: 2.3.2 Reporter: Stanilslav Spiridonov See MRELEASE-702, all the same but scm is HG. Plugin version is 2.3.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-67) Add a way to merge inherited profiles with same id
[
https://jira.codehaus.org/browse/MPH-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-67:
--
Component/s: effective-pom
Add a way to merge inherited profiles with same id
--
Key: MPH-67
URL: https://jira.codehaus.org/browse/MPH-67
Project: Maven 2.x Help Plugin
Issue Type: Bug
Components: effective-pom
Affects Versions: 2.1
Reporter: Vincent Siveton
Fix For: Backlog
Take the following project:
{noformat}
apache:6:pom with has a apache-release profileId
|_ maven-parent:12
|_ doxia:1.1.2-SNAPSHOT with has a apache-release profileId
{noformat}
Call /doxia/doxia/mvn help:effective-pom -N
You will see only the apache-release from Doxia but Maven uses the
apache-release from parent.
Two way to see in the effective pom the inherited profiles with same id:
* merge child and parent profiles
* add parent profile with another id
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-53) mvn help:describe returns the version that is specified in metadata instead of the one in the parent pom
[
https://jira.codehaus.org/browse/MPH-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319779#comment-319779
]
Robert Scholte commented on MPH-53:
---
I've found a problem for M3.0.4:
{code:title=org.apache.maven.plugin.internal.DefaultPluginManager.verifyPlugin(Plugin,
MavenProject, Settings, ArtifactRepository)}
...
if ( plugin.getVersion() == null )
{
PluginVersionRequest versionRequest =
new DefaultPluginVersionRequest( plugin,
session.getRepositorySession(),
project.getRemotePluginRepositories() );
plugin.setVersion( pluginVersionResolver.resolve( versionRequest
).getVersion() );
}
...
{code}
The {{Model}} is not passed to the {{versionRequest}}, so the version is
resolved based on repositories.
There's no clear description of what the {{verifyPlugin()}} should do, so it's
hard to tell if we can just add the {{Model}}.
mvn help:describe returns the version that is specified in metadata instead
of the one in the parent pom
-
Key: MPH-53
URL: https://jira.codehaus.org/browse/MPH-53
Project: Maven 2.x Help Plugin
Issue Type: Bug
Components: describe
Affects Versions: 2.0.1
Environment: windows xp
tested with mvn 2.0.8 2.0.9
Reporter: Rintcius Blok
Fix For: Backlog
{{mvn help:describe}} returns a different version than {{mvn
help:effective-pom}} returns:
{noformat}
mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
{noformat}
However, when I run {{mvn help:effective-pom}}
I get
{code:xml}
...
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
testFailureIgnoretrue/testFailureIgnore
includes
include**/*Test.java/include
/includes
formathtml/format
/configuration
/plugin
/plugins
/pluginManagement
...
{code}
My pom structure is quite simple: just a parent {{pom.xml}} with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-83) all-profiles should list profiles from settings.xml even if there is no project
[ https://jira.codehaus.org/browse/MPH-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MPH-83. - Resolution: Cannot Reproduce Assignee: Robert Scholte Tested with M2.2.1 and M3.0.4 and works fine. For previous M3 versions it did not work due to MNG-5224 IT improved with [r1446764|http://svn.apache.org/r1446764] all-profiles should list profiles from settings.xml even if there is no project --- Key: MPH-83 URL: https://jira.codehaus.org/browse/MPH-83 Project: Maven 2.x Help Plugin Issue Type: Bug Components: all-profiles Affects Versions: 2.1.1 Reporter: Julien Nicoulaud Assignee: Robert Scholte Running the goal all-profiles somewhere outside of a project answers No profile detected !. I have active and inactive profiles in my settings.xml, they should appear. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3131) Error message is misleading if a missing plugin parameter is of a type like List
[
https://jira.codehaus.org/browse/MNG-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-3131.
---
Resolution: Fixed
Fix Version/s: (was: Issues to be reviewed for 3.x)
3.0.5
Assignee: Robert Scholte
Fixed in http://git-wip-us.apache.org/repos/asf/maven/commit/56cd921f
Error message is misleading if a missing plugin parameter is of a type like
List
Key: MNG-3131
URL: https://jira.codehaus.org/browse/MNG-3131
Project: Maven 2 3
Issue Type: Bug
Reporter: Dennis Lundberg
Assignee: Robert Scholte
Fix For: 3.0.5
Here is a sample output I got when I was working on the changes-plugin:
{code}
[INFO] One or more required plugin parameters are invalid/missing for
'changes:announcement-mail'
[0] inside the definition for plugin: 'maven-changes-plugin'specify the
following:
configuration
...
smtpHostVALUE/smtpHost
/configuration.
[1] inside the definition for plugin: 'maven-changes-plugin'specify the
following:
configuration
...
toAddressesVALUE/toAddresses
/configuration.
{code}
Notice the second parameter toAdresses. It is of the type List, so the
correct configuration would be something like this
{code}
configuration
...
toAddresses
toAddressVALUE/toAddress
/toAddresses
/configuration.
{code}
I haven't found where in the code base the handling of List/Map/Array
parameters is. That code could probably be borrowed/reused in
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterException.java
which is the class responsible for formating the above messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-712) using maven-scm-plugin to checkin folder and file
[
https://jira.codehaus.org/browse/SCM-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MNG-5223 to SCM-712:
-
Component/s: (was: Errors)
(was: Plugin API)
maven-plugin
Affects Version/s: (was: 2.2.1)
Key: SCM-712 (was: MNG-5223)
Project: Maven SCM (was: Maven 2 3)
using maven-scm-plugin to checkin folder and file
-
Key: SCM-712
URL: https://jira.codehaus.org/browse/SCM-712
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin
Environment: software platform
Reporter: Rajasekar
step 1.Checkout Content
execution
idcheckout folder/id
phaseprocess-resources/phase
configuration
basedir/home/checking-folder/basedir
revisionKeyapp.data.revision/revisionKey
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goalcheckout/goal
/goals
/execution
step 2. jar adding
execution
idadd jar/id
phaseprocess-resources/phase
configuration
includes*.*/includes
includes**/*/includes
basedir/home/checking-folder/basedir
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goaladd/goal
/goals
/execution
step 3. checkin in new folder and jar
execution
idcheckin- jar/id
phaseprocess-resources/phase
configuration
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
message${rdpv.chk.message}/message
basedir/home/checking-folder/basedir
revisionKeyapp.data.revision/revisionKey
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goalcheckin/goal
/goals
/execution
After checking out using step 1, I am creating one New folder in
/home/checking-folder, after that i am moving one jar inside that New
folder. while running the 2nd step and 3rd step it shows new created folder
is not working copy.
Please help me to check-in jar with new created folder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-712) using maven-scm-plugin to checkin folder and file
[
https://jira.codehaus.org/browse/SCM-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-712:
---
Description:
step 1.Checkout Content
{code:xml}
execution
idcheckout folder/id
phaseprocess-resources/phase
configuration
basedir/home/checking-folder/basedir
revisionKeyapp.data.revision/revisionKey
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goalcheckout/goal
/goals
/execution
{code}
step 2. jar adding
{code:xml}
execution
idadd jar/id
phaseprocess-resources/phase
configuration
includes*.*/includes
includes**/*/includes
basedir/home/checking-folder/basedir
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goaladd/goal
/goals
/execution
{code}
step 3. checkin in new folder and jar
{code:xml}
execution
idcheckin- jar/id
phaseprocess-resources/phase
configuration
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
message${rdpv.chk.message}/message
basedir/home/checking-folder/basedir
revisionKeyapp.data.revision/revisionKey
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goalcheckin/goal
/goals
/execution
{code}
After checking out using step 1, I am creating one New folder in
/home/checking-folder, after that i am moving one jar inside that New folder.
while running the 2nd step and 3rd step it shows new created folder is not
working copy.
Please help me to check-in jar with new created folder.
was:
step 1.Checkout Content
execution
idcheckout folder/id
phaseprocess-resources/phase
configuration
basedir/home/checking-folder/basedir
revisionKeyapp.data.revision/revisionKey
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goalcheckout/goal
/goals
/execution
step 2. jar adding
execution
idadd jar/id
phaseprocess-resources/phase
configuration
includes*.*/includes
includes**/*/includes
basedir/home/checking-folder/basedir
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goaladd/goal
/goals
/execution
step 3. checkin in new folder and jar
execution
idcheckin- jar/id
phaseprocess-resources/phase
configuration
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
message${rdpv.chk.message}/message
basedir/home/checking-folder/basedir
revisionKeyapp.data.revision/revisionKey
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goalcheckin/goal
/goals
/execution
After checking out using step 1, I am creating one New folder in
/home/checking-folder, after that i am moving one jar inside that New folder.
while running the 2nd step and 3rd step it shows new created folder is not
working copy.
Please help me to check-in jar with new created folder.
using maven-scm-plugin to checkin folder and file
-
Key: SCM-712
URL: https://jira.codehaus.org/browse/SCM-712
Project: Maven SCM
Issue Type: Bug
Components: maven-plugin
Environment: software platform
Reporter: Rajasekar
step 1.Checkout Content
{code:xml}
execution
idcheckout folder/id
phaseprocess-resources/phase
configuration
basedir/home/checking-folder/basedir
revisionKeyapp.data.revision/revisionKey
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goalcheckout/goal
/goals
/execution
{code}
step 2. jar adding
{code:xml}
execution
idadd jar/id
phaseprocess-resources/phase
configuration
includes*.*/includes
includes**/*/includes
basedir/home/checking-folder/basedir
connectionUrlscm:svn:https://www.test.com/project-folder/connectionUrl
username${svn.username}/username
password${svn.password}/password
/configuration
goals
goaladd/goal
/goals
/execution
{code}
step 3. checkin in new folder and jar
{code:xml}
execution
[jira] (MNG-864) Fail the build with a nice error message if a property to be interpolated in pom.xml is not defined
[
https://jira.codehaus.org/browse/MNG-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-864.
--
Resolution: Won't Fix
Fix Version/s: (was: Issues to be reviewed for 3.x)
Assignee: Robert Scholte
This is superseded by the Maven Enforcer Plugin,
http://maven.apache.org/enforcer/enforcer-rules/
It has the {{requireEnvironmentVariable}}, so you have full control over which
variables are required and what the message should be.
Fail the build with a nice error message if a property to be interpolated in
pom.xml is not defined
---
Key: MNG-864
URL: https://jira.codehaus.org/browse/MNG-864
Project: Maven 2 3
Issue Type: Improvement
Components: Plugins and Lifecycle
Affects Versions: 2.0-alpha-3
Reporter: Vincent Massol
Assignee: Robert Scholte
Priority: Minor
There are uses cases with pom.xml requiring an environment-specific property
to be defined. If those property are not provided by the user in a
settings.xm, profiles.xml or a command-line system property then m2 should
fail the build with a nice error explaiing the reason.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5320) java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment
[
https://jira.codehaus.org/browse/MNG-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5320:
Description:
Attempting to build jaxen from
https://fisheye.codehaus.org/browse/jaxen/trunk/jaxen/pom.xml?r=1382
This may well be caused by a plugin mismatch problem, but since the error
message asked that I report it here you go.
{noformat}
[WARNING] An issue has occurred with report
org.apache.maven.plugin.changelog.DeveloperActivityReport, skip LinkageError
org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment()V, please report
an issue to Maven dev team.
java.lang.NoSuchMethodError:
org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment()V
at
org.apache.maven.scm.provider.svn.svnexe.command.SvnCommandLineUtils.getBaseSvnCommandLine(SvnCommandLineUtils.java:82)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.createCommandLine(SvnChangeLogCommand.java:121)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.executeChangeLogCommand(SvnChangeLogCommand.java:77)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.executeChangeLogCommand(SvnChangeLogCommand.java:68)
at
org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:101)
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:58)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:371)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.changelog(AbstractSvnScmProvider.java:274)
at
org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:250)
at
org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:226)
at
org.apache.maven.plugin.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:534)
at
org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:393)
at
org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] Generating File Activity report--- maven-changelog-plugin:2.1
[INFO] Generating changed sets xml to: /Volumes/Macintosh
HD/Users/elharo/Projects/workspace/jaxen/target/changelog.xml
[WARNING] An issue has occurred with report
[jira] (MNG-5320) java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment
[
https://jira.codehaus.org/browse/MNG-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5320.
---
Resolution: Incomplete
Assignee: Robert Scholte
No feedback, so closing it.
FYI, current most recent version of the Maven Changelog Plugin is 2.2
java.lang.NoSuchMethodError:
org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment
--
Key: MNG-5320
URL: https://jira.codehaus.org/browse/MNG-5320
Project: Maven 2 3
Issue Type: Bug
Components: Sites Reporting
Affects Versions: 3.0.4
Environment: Mac OS X, Maven 3.0.4, java version 1.6.0_33
Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-10M3720)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)
Reporter: Elliotte Rusty Harold
Assignee: Robert Scholte
Priority: Minor
Attempting to build jaxen from
https://fisheye.codehaus.org/browse/jaxen/trunk/jaxen/pom.xml?r=1382
This may well be caused by a plugin mismatch problem, but since the error
message asked that I report it here you go.
{noformat}
[WARNING] An issue has occurred with report
org.apache.maven.plugin.changelog.DeveloperActivityReport, skip LinkageError
org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment()V, please
report an issue to Maven dev team.
java.lang.NoSuchMethodError:
org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment()V
at
org.apache.maven.scm.provider.svn.svnexe.command.SvnCommandLineUtils.getBaseSvnCommandLine(SvnCommandLineUtils.java:82)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.createCommandLine(SvnChangeLogCommand.java:121)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.executeChangeLogCommand(SvnChangeLogCommand.java:77)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.executeChangeLogCommand(SvnChangeLogCommand.java:68)
at
org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:101)
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:58)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:371)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.changelog(AbstractSvnScmProvider.java:274)
at
org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:250)
at
org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:226)
at
org.apache.maven.plugin.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:534)
at
org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:393)
at
org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
[jira] (MNG-4188) Add a 'finally' phase.
[
https://jira.codehaus.org/browse/MNG-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=319817#comment-319817
]
Robert Scholte commented on MNG-4188:
-
Maybe a {{finally}}-phase is not the right solution.
There are several phases which always belong together:
* pre-integration-test, integration-test, post-integration-test
* pre-clean, clean, post-clean
* pre-site, site, post-site
In all these cases it makes more sense to have the following construction:
{code}
try
{
// execute pre-P
// execute P
}
finally
{
// execute post-P
}
{code}
But we would still need a mechanism for those users who really, really want to
execute up until the specified phase.
Maybe something like {{mvn integration-test.}} //notice the end-dot!
Add a 'finally' phase.
--
Key: MNG-4188
URL: https://jira.codehaus.org/browse/MNG-4188
Project: Maven 2 3
Issue Type: Wish
Components: Plugins and Lifecycle
Affects Versions: Issues to be reviewed for 3.x
Reporter: Christian Schulte
Priority: Minor
Fix For: Issues to be reviewed for 3.x
When Maven executes a lifecycle, it does not execute any phases succeeding a
failing phase. It would be great if Maven supports a 'finally' phase, which
is guaranteed to run regardless of the state of the lifecycle just like a
Java 'finally' block. The use case I would need such a phase for is the
following:
{code}
profile
idsourceforge-shell/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
dependencies
dependency
groupIdorg.apache.ant/groupId
artifactIdant-jsch/artifactId
version1.7.1/version
/dependency
/dependencies
executions
execution
idcreate-sourceforge-shell/id
phasevalidate/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idcreate-sourceforge-shell-site/id
phasepre-site/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=create timeout=30 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell/id
phasedeploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
execution
idshutdown-sourceforge-shell-site/id
phasesite-deploy/phase
goals
goalrun/goal
/goals
configuration
tasks
sshexec host=shell.sourceforge.net
username=${sf.username},${sf.project} password=${sf.password}
command=shutdown timeout=30 /
echo message=Sleeping for 1 minute waiting for shutdown
of shell. /
sleep minutes=1 /
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
I am currently using this profile when deploying to sourceforge. The problem
is, that the shell won't get shutdown, whenever a build fails. It needs to
get shutdown, so that a build for another SF project can succeed. In the
example above, the two executions 'shutdown-sourceforge-shell' and
'shutdown-sourceforge-shell-site' could be bound to a 'finally' phase and
could shutdown the shell regardless of the outcome of the build.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
[jira] (MNG-5349) NullPointerException if missing id in org.apache.maven.lifecycle.Lifecycle
[
https://jira.codehaus.org/browse/MNG-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5349:
Description:
I've been working with custom lifecycles, and accidentally left the id out of
one of them. You can see it in this example where I commented out the key line
(everything works fine if this line is uncommented):
{code:xml}
component-set
components
component
roleorg.apache.maven.lifecycle.mapping.LifecycleMapping/role
role-hintphase-test/role-hint
implementation
org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
/implementation
/component
component
roleorg.apache.maven.lifecycle.Lifecycle/role
role-hintphase-test/role-hint
implementationorg.apache.maven.lifecycle.Lifecycle/implementation
configuration
!-- idphase-test/id --
phases
phasetp-pre-new-phase/phase
phasetp-new-phase/phase
phasetp-post-new-phase/phase
/phases
default-phases
tp-new-phaseorg.riedl:phase-test-maven-plugin:greet/tp-new-phase
/default-phases
/configuration
/component
/components
/component-set
~
{code}
Here's most of the stack trace:
{noformat}
(macro: ~/Src/lenskit-projects/tryout-phase-test-plugin) mvn tp-post-new-phase
[INFO] Scanning for projects...
[ERROR] Internal error: java.lang.NullPointerException - [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NullPointerException
at java.lang.String.compareTo(String.java:1167)
at
org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer$1.compare(DefaultLifecyclePluginAnalyzer.java:144)
at
org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer$1.compare(DefaultLifecyclePluginAnalyzer.java:140)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getOrderedLifecycles(DefaultLifecyclePluginAnalyzer.java:139)
at
org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:96)
at
org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:63)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:397)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:371)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:560)
{noformat}
The NullPointerException happens with most attempts to run the project, such as
mvn foo. I've attached the pom.xml, lifecycles.xml, components.xml, and the
Java for the plugin. I think only components.xml is relevant.
was:
I've been working with custom lifecycles, and accidentally left the id out of
one of them. You can see it in this example where I commented out the key line
(everything works fine if this line is uncommented):
component-set
components
component
roleorg.apache.maven.lifecycle.mapping.LifecycleMapping/role
role-hintphase-test/role-hint
implementation
org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
/implementation
/component
component
roleorg.apache.maven.lifecycle.Lifecycle/role
role-hintphase-test/role-hint
implementationorg.apache.maven.lifecycle.Lifecycle/implementation
configuration
!-- idphase-test/id --
phases
phasetp-pre-new-phase/phase
phasetp-new-phase/phase
phasetp-post-new-phase/phase
/phases
default-phases
