[jira] Created: (MANTRUN-168) Support for setting and overriding value
Support for setting and overriding value - Key: MANTRUN-168 URL: https://jira.codehaus.org/browse/MANTRUN-168 Project: Maven 2.x Antrun Plugin Issue Type: New Feature Affects Versions: 1.6 Environment: All Reporter: Darryl L. Miles Priority: Minor Have rough patch, am testing and considering unit tests to verify implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-210) Maven2OsgiConverter provide simple mechanism for more than 3 version part conversion
Maven2OsgiConverter provide simple mechanism for more than 3 version part
conversion
Key: MSHARED-210
URL: https://jira.codehaus.org/browse/MSHARED-210
Project: Maven Shared Components
Issue Type: New Feature
Reporter: Darryl L. Miles
At the moment the default Maven2OsgiConverter implementation truncates the
version number after the 3rd part.
1.2.3.4.5.20111019-SNAPSHOT => 1.2.3.SNAPSHOT
This request is to provide a mechanism to allow a fully numeric part to be
padded with leading zeros like:
1.2.3.4.5.20111019-SNAPSHOT => 1.2.00300400520111019.SNAPSHOT
1.2.20111019-SNAPSHOT => 1.2.20111019.SNAPSHOT
1.2.3.20111019-SNAPSHOT => 1.2.00320111019.SNAPSHOT
The only option the user needs to supply in configuration is the number of
places to pad it out to, if the part is already that long (or longer) then no
extra padding is added. Maybe the default is 3 (or an automatic default of).
I think this kind of conversion should be an option built into the stock
Maven/OSGi integration, you are converting a valid Maven version number into a
valid OSGi version number and providing a mechanism to loose the least amount
of precision of information.
A really nice to have feature would be an option to specify a formatter
%{03:1}.%{2}.%{06:3} where all padding presumes leading zeros (never spaces),
where is uses some other Java convention for String formatting, where the
output must have no more than 3 full-stop characters in it (and other
validation fules). So a sub-set of String formatter rules but allowing total
control. Any parts not conforming to the rules would cause plugin build
failure and suitable conversion error.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANTRUN-173) maven-antrun-plugin not forward compatible with maven 3.
[
https://jira.codehaus.org/browse/MANTRUN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353635#comment-353635
]
Darryl L. Miles commented on MANTRUN-173:
-
What is it you need to reproduce ? Maybe you can describe what you tried.
Based on reading the report a skilled Java developer might do the following
steps:
This is how to verify the bytecode is invoking
1) Install and setup Maven 2.0.1 in the current shell as the default. Verify
with "mvn -v"
2) Checkout this target project (the version listed in the report,
maven-antrun-plugin:1.7)
3) Run "mvn dependency:tree" confirm the JARs and version being used the
project.
4) Run "mvn dependency:copy-dependencies" to download all these dependencies.
5) Now locate the JARs/*.class of the invoking code shown in the exception
(this would be:
org.apache.maven.artifact.ant.AbstractArtifactTask.readSettings(AbstractArtifactTask.java:382))
and confirm the signature it invokes on. This would be
org/apache/maven/settings/RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V.
6) Now try to locate this method (from inside the Maven 2 install base, not a
Maven 3 install base!) You should find this APIs was only added during Maven
3, but the MANTRUN plugin claims to support Maven 2, but it does not.
7) Apply the patches.
> maven-antrun-plugin not forward compatible with maven 3.
>
>
> Key: MANTRUN-173
> URL: https://jira.codehaus.org/browse/MANTRUN-173
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Windows 7, Maven 3, Java 1.6
>Reporter: Peter Sherwood
>Assignee: Karl-Heinz Marbaise
>Priority: Critical
> Attachments: MANTRUN173b-o.a.m.p.mmap.patch,
> MANTRUN173-o.a.m.p.mmap.patch, mavenerror.txt
>
>
> In some environments we do not have a Nexus style repository and so to make
> an out of the box build cycle we use antrun to install a jar into a local
> repository. This works absolutely fine with no exceptions in Maven 2.2.1 in
> the same environment mentioned above. Moving directly to Maven 3 the build
> does not work and records the following exception:
> {noformat}
> Caused by: java.lang.NoSuchMethodError:
> org/apache/maven/settings/RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.readSettings(AbstractArtifactTask.java:382)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.loadSettings(AbstractArtifactTask.java:311)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:278)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getSettings(AbstractArtifactTask.java:223)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getDefaultLocalRepository(AbstractArtifactTask.java:212)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getLocalRepository(AbstractArtifactTask.java:700)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:110)
> at org.apache.maven.artifact.ant.Pom.getMavenProject(Pom.java:272)
> at org.apache.maven.artifact.ant.Pom.setVersion(Pom.java:570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at
> org.apache.tools.ant.IntrospectionHelper$AttributeSetter.setObject(IntrospectionHelper.java:1498)
> at
> org.apache.tools.ant.IntrospectionHelper.setAttribute(IntrospectionHelper.java:405)
> ... 38 more
> {noformat}
> My POM is as follows and has been cut down to show the problem only.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
> 4.0.0
> MavenAntTest
> MavenAntTest
> 1.0
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.7
>
>
> initialize
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> path="${settings.localRepository}${file.separator}org${file.separator}apache${file.separator}maven${file.separator}maven-ant-tasks${file.separator}2.1.3${file.separ
[jira] (MANTRUN-173) maven-antrun-plugin not forward compatible with maven 3.
[
https://jira.codehaus.org/browse/MANTRUN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353636#comment-353636
]
Darryl L. Miles commented on MANTRUN-173:
-
NO IDEA HOW TO REOPEN THAT BUTTON DOES NOT EXIST, GOING TO CLONE AND/OR CREATE
REOPEN BUG AS A NEW REPORT POINTING TO THIS.
> maven-antrun-plugin not forward compatible with maven 3.
>
>
> Key: MANTRUN-173
> URL: https://jira.codehaus.org/browse/MANTRUN-173
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Windows 7, Maven 3, Java 1.6
>Reporter: Peter Sherwood
>Assignee: Karl-Heinz Marbaise
>Priority: Critical
> Attachments: MANTRUN173b-o.a.m.p.mmap.patch,
> MANTRUN173-o.a.m.p.mmap.patch, mavenerror.txt
>
>
> In some environments we do not have a Nexus style repository and so to make
> an out of the box build cycle we use antrun to install a jar into a local
> repository. This works absolutely fine with no exceptions in Maven 2.2.1 in
> the same environment mentioned above. Moving directly to Maven 3 the build
> does not work and records the following exception:
> {noformat}
> Caused by: java.lang.NoSuchMethodError:
> org/apache/maven/settings/RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.readSettings(AbstractArtifactTask.java:382)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.loadSettings(AbstractArtifactTask.java:311)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:278)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getSettings(AbstractArtifactTask.java:223)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getDefaultLocalRepository(AbstractArtifactTask.java:212)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getLocalRepository(AbstractArtifactTask.java:700)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:110)
> at org.apache.maven.artifact.ant.Pom.getMavenProject(Pom.java:272)
> at org.apache.maven.artifact.ant.Pom.setVersion(Pom.java:570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at
> org.apache.tools.ant.IntrospectionHelper$AttributeSetter.setObject(IntrospectionHelper.java:1498)
> at
> org.apache.tools.ant.IntrospectionHelper.setAttribute(IntrospectionHelper.java:405)
> ... 38 more
> {noformat}
> My POM is as follows and has been cut down to show the problem only.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
> 4.0.0
> MavenAntTest
> MavenAntTest
> 1.0
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.7
>
>
> initialize
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> path="${settings.localRepository}${file.separator}org${file.separator}apache${file.separator}maven${file.separator}maven-ant-tasks${file.separator}2.1.3${file.separator}maven-ant-tasks-2.1.3.jar"
> />
> resource="org/apache/maven/artifact/ant/antlib.xml"
>
> uri="antlib:org.apache.maven.artifact.ant"
> classpathref="maven-ant-tasks.classpath" />
> resource="net/sf/antcontrib/antcontrib.properties"
>
> classpathref="maven.plugin.classpath" />
> groupId="net.sf.saxon" artifactId="saxon"
> version="9.3.0.5" name="Saxon
> XSLT Parser">
>
>
> file="${settings.localRepository}${file.separator}net${file.separator}sf${file.separator}saxon${file.separator}saxon${file.separator}9.3.0.5${file.separator}saxon-9.3.0.5.jar"
> type="file" />
>
>
>
[jira] (MANTRUN-168) Support for setting and overriding value
[ https://jira.codehaus.org/browse/MANTRUN-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Miles updated MANTRUN-168: Attachment: o.a.m.p.mmap.patch @since 1.7 This also corrects a matter concerning escaping of special XML characters when generating the *.xml file for ANT. There are probably other places in the file that should use the method to escape the names. Also need to check use of StringBuilder v StringBuffer. > Support for setting and overriding value > - > > Key: MANTRUN-168 > URL: https://jira.codehaus.org/browse/MANTRUN-168 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.6 > Environment: All >Reporter: Darryl L. Miles >Priority: Minor > Attachments: o.a.m.p.mmap.patch > > > Have rough patch, am testing and considering unit tests to verify > implementation. -- 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] (MANTRUN-168) Support for setting and overriding value
[ https://jira.codehaus.org/browse/MANTRUN-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307739#comment-307739 ] Darryl L. Miles commented on MANTRUN-168: - I guess I forget about this change until I found time to start to unloading my local WIP trees recently. > Support for setting and overriding value > - > > Key: MANTRUN-168 > URL: https://jira.codehaus.org/browse/MANTRUN-168 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.6 > Environment: All >Reporter: Darryl L. Miles >Priority: Minor > Attachments: o.a.m.p.mmap.patch > > > Have rough patch, am testing and considering unit tests to verify > implementation. -- 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] (MANTRUN-173) maven-antrun-plugin not forward compatible with maven 3.
[
https://jira.codehaus.org/browse/MANTRUN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307740#comment-307740
]
Darryl L. Miles commented on MANTRUN-173:
-
...\m2-repository\org\apache\maven\maven-settings\2.0.11\maven-settings-2.0.11.jar
org.apache.maven.settings.RuntimeInfo.class
public RuntimeInfo( Settings settings )
This ctor does exist in that version. I think the issue for you is that you
need to manually add the dependency for org.apache.maven:maven-core:3.x.x
(fixup for your version of Maven runtime). I can only think the classpath
container is denying visibility.
As a workaround I think you can manually add this dependency to the pom.xml for
the plugin.
The issue is that the module org.apache.maven:maven-project:3.x.x does not
exist in Maven3.
Please find enclosed a patch for the pom.xml for the MANTRUN project's pom that
allows it to build against Maven 3.
Then find a recommended patch for the current project that will both maintain
compatibility with Maven 2 as well as be forward looking to allow the plugin to
work on Maven3 (this is in theory). This adds the reference to maven-core
project which is need to provide such things as org.apache.maven.project.*
namespace that is used by MANTRUN.
I am not sure what the release policy is for MANTRUN (I did not look it up).
> maven-antrun-plugin not forward compatible with maven 3.
>
>
> Key: MANTRUN-173
> URL: https://jira.codehaus.org/browse/MANTRUN-173
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Windows 7, Maven 3, Java 1.6
>Reporter: Peter Sherwood
>Priority: Critical
> Attachments: mavenerror.txt
>
>
> In some environments we do not have a Nexus style repository and so to make
> an out of the box build cycle we use antrun to install a jar into a local
> repository. This works absolutely fine with no exceptions in Maven 2.2.1 in
> the same environment mentioned above. Moving directly to Maven 3 the build
> does not work and records the following exception:
> Caused by: java.lang.NoSuchMethodError:
> org/apache/maven/settings/RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.readSettings(AbstractArtifactTask.java:382)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.loadSettings(AbstractArtifactTask.java:311)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:278)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getSettings(AbstractArtifactTask.java:223)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getDefaultLocalRepository(AbstractArtifactTask.java:212)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getLocalRepository(AbstractArtifactTask.java:700)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:110)
> at org.apache.maven.artifact.ant.Pom.getMavenProject(Pom.java:272)
> at org.apache.maven.artifact.ant.Pom.setVersion(Pom.java:570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at
> org.apache.tools.ant.IntrospectionHelper$AttributeSetter.setObject(IntrospectionHelper.java:1498)
> at
> org.apache.tools.ant.IntrospectionHelper.setAttribute(IntrospectionHelper.java:405)
> ... 38 more
> My POM is as follows and has been cut down to show the problem only.
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
> 4.0.0
> MavenAntTest
> MavenAntTest
> 1.0
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.7
>
>
> initialize
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> path="${settings.localRepository}${file.separator}org${file.separator}apache${file.separator}maven${file.separator}maven-ant-tasks${file.separator}2.1.3${file.separator}maven-ant-tasks-2.1.3.jar"
> />
> resource="org/apache/maven/art
[jira] (MANTRUN-173) maven-antrun-plugin not forward compatible with maven 3.
[
https://jira.codehaus.org/browse/MANTRUN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Miles updated MANTRUN-173:
Attachment: MANTRUN173-o.a.m.p.mmap.patch
This is a patch showing a port of MANTRUN from Maven 2.x to Maven 3.x seems
straight forward.
Maybe this could form a new release of MANTRUN for version 2.x of the plugin
(or maybe just skip 2.x and go to 3.x to track the version of Maven). Whatever.
> maven-antrun-plugin not forward compatible with maven 3.
>
>
> Key: MANTRUN-173
> URL: https://jira.codehaus.org/browse/MANTRUN-173
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Windows 7, Maven 3, Java 1.6
>Reporter: Peter Sherwood
>Priority: Critical
> Attachments: MANTRUN173-o.a.m.p.mmap.patch, mavenerror.txt
>
>
> In some environments we do not have a Nexus style repository and so to make
> an out of the box build cycle we use antrun to install a jar into a local
> repository. This works absolutely fine with no exceptions in Maven 2.2.1 in
> the same environment mentioned above. Moving directly to Maven 3 the build
> does not work and records the following exception:
> Caused by: java.lang.NoSuchMethodError:
> org/apache/maven/settings/RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.readSettings(AbstractArtifactTask.java:382)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.loadSettings(AbstractArtifactTask.java:311)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:278)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getSettings(AbstractArtifactTask.java:223)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getDefaultLocalRepository(AbstractArtifactTask.java:212)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getLocalRepository(AbstractArtifactTask.java:700)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:110)
> at org.apache.maven.artifact.ant.Pom.getMavenProject(Pom.java:272)
> at org.apache.maven.artifact.ant.Pom.setVersion(Pom.java:570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at
> org.apache.tools.ant.IntrospectionHelper$AttributeSetter.setObject(IntrospectionHelper.java:1498)
> at
> org.apache.tools.ant.IntrospectionHelper.setAttribute(IntrospectionHelper.java:405)
> ... 38 more
> My POM is as follows and has been cut down to show the problem only.
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
> 4.0.0
> MavenAntTest
> MavenAntTest
> 1.0
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.7
>
>
> initialize
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> path="${settings.localRepository}${file.separator}org${file.separator}apache${file.separator}maven${file.separator}maven-ant-tasks${file.separator}2.1.3${file.separator}maven-ant-tasks-2.1.3.jar"
> />
> resource="org/apache/maven/artifact/ant/antlib.xml"
>
> uri="antlib:org.apache.maven.artifact.ant"
> classpathref="maven-ant-tasks.classpath" />
> resource="net/sf/antcontrib/antcontrib.properties"
>
> classpathref="maven.plugin.classpath" />
> groupId="net.sf.saxon" artifactId="saxon"
> version="9.3.0.5" name="Saxon
> XSLT Parser">
>
>
> file="${settings.localRepository}${file.separator}net${file.separator}sf${file.separator}saxon${file.separator}saxon${file.separator}9.3.0.5${file.separator}saxon-9.3.0.5.jar"
> type="file" />
>
>
[jira] (MANTRUN-173) maven-antrun-plugin not forward compatible with maven 3.
[
https://jira.codehaus.org/browse/MANTRUN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Miles updated MANTRUN-173:
Attachment: MANTRUN173b-o.a.m.p.mmap.patch
This is a patch for inclusion in MANTRUN for the 1.x (1.7/1.8) releases.
This should maintain existing compatibility (because a dead/unrequired extra
dependency does not harm usage, even if not the most efficient).
The for Maven 3.x users it will allow this plugin to just work without change.
USE THIS PATCH FIRST IN THIS 'MANTRUN' PROJECT
> maven-antrun-plugin not forward compatible with maven 3.
>
>
> Key: MANTRUN-173
> URL: https://jira.codehaus.org/browse/MANTRUN-173
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Windows 7, Maven 3, Java 1.6
>Reporter: Peter Sherwood
>Priority: Critical
> Attachments: MANTRUN173b-o.a.m.p.mmap.patch,
> MANTRUN173-o.a.m.p.mmap.patch, mavenerror.txt
>
>
> In some environments we do not have a Nexus style repository and so to make
> an out of the box build cycle we use antrun to install a jar into a local
> repository. This works absolutely fine with no exceptions in Maven 2.2.1 in
> the same environment mentioned above. Moving directly to Maven 3 the build
> does not work and records the following exception:
> Caused by: java.lang.NoSuchMethodError:
> org/apache/maven/settings/RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.readSettings(AbstractArtifactTask.java:382)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.loadSettings(AbstractArtifactTask.java:311)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:278)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getSettings(AbstractArtifactTask.java:223)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getDefaultLocalRepository(AbstractArtifactTask.java:212)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getLocalRepository(AbstractArtifactTask.java:700)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:110)
> at org.apache.maven.artifact.ant.Pom.getMavenProject(Pom.java:272)
> at org.apache.maven.artifact.ant.Pom.setVersion(Pom.java:570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at
> org.apache.tools.ant.IntrospectionHelper$AttributeSetter.setObject(IntrospectionHelper.java:1498)
> at
> org.apache.tools.ant.IntrospectionHelper.setAttribute(IntrospectionHelper.java:405)
> ... 38 more
> My POM is as follows and has been cut down to show the problem only.
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
> 4.0.0
> MavenAntTest
> MavenAntTest
> 1.0
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.7
>
>
> initialize
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> path="${settings.localRepository}${file.separator}org${file.separator}apache${file.separator}maven${file.separator}maven-ant-tasks${file.separator}2.1.3${file.separator}maven-ant-tasks-2.1.3.jar"
> />
> resource="org/apache/maven/artifact/ant/antlib.xml"
>
> uri="antlib:org.apache.maven.artifact.ant"
> classpathref="maven-ant-tasks.classpath" />
> resource="net/sf/antcontrib/antcontrib.properties"
>
> classpathref="maven.plugin.classpath" />
> groupId="net.sf.saxon" artifactId="saxon"
> version="9.3.0.5" name="Saxon
> XSLT Parser">
>
>
> file="${settings.localRepository}${file.separator}net${file.separator}sf${file.separator}saxon${file.separator}saxon${file.separator}9.3.0.5${file.sep
[jira] (MANTRUN-173) maven-antrun-plugin not forward compatible with maven 3.
[
https://jira.codehaus.org/browse/MANTRUN-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307742#comment-307742
]
Darryl L. Miles edited comment on MANTRUN-173 at 9/4/12 6:24 PM:
-
This is a patch for inclusion in MANTRUN for the 1.x (1.7/1.8) releases.
This should maintain existing compatibility (because a dead/unrequired extra
dependency does not harm usage, even if not the most efficient).
Then for Maven 3.x users it will allow this plugin to just work without change.
However I am not at all sure how Maven 3.x manages to resolve
org.apache.maven:maven-project:3.x since that does not exist.
USE THIS PATCH FIRST IN THIS 'MANTRUN' PROJECT
was (Author: dlmiles):
This is a patch for inclusion in MANTRUN for the 1.x (1.7/1.8) releases.
This should maintain existing compatibility (because a dead/unrequired extra
dependency does not harm usage, even if not the most efficient).
The for Maven 3.x users it will allow this plugin to just work without change.
USE THIS PATCH FIRST IN THIS 'MANTRUN' PROJECT
> maven-antrun-plugin not forward compatible with maven 3.
>
>
> Key: MANTRUN-173
> URL: https://jira.codehaus.org/browse/MANTRUN-173
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Windows 7, Maven 3, Java 1.6
>Reporter: Peter Sherwood
>Priority: Critical
> Attachments: MANTRUN173b-o.a.m.p.mmap.patch,
> MANTRUN173-o.a.m.p.mmap.patch, mavenerror.txt
>
>
> In some environments we do not have a Nexus style repository and so to make
> an out of the box build cycle we use antrun to install a jar into a local
> repository. This works absolutely fine with no exceptions in Maven 2.2.1 in
> the same environment mentioned above. Moving directly to Maven 3 the build
> does not work and records the following exception:
> Caused by: java.lang.NoSuchMethodError:
> org/apache/maven/settings/RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.readSettings(AbstractArtifactTask.java:382)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.loadSettings(AbstractArtifactTask.java:311)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:278)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getSettings(AbstractArtifactTask.java:223)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getDefaultLocalRepository(AbstractArtifactTask.java:212)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.getLocalRepository(AbstractArtifactTask.java:700)
> at
> org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:110)
> at org.apache.maven.artifact.ant.Pom.getMavenProject(Pom.java:272)
> at org.apache.maven.artifact.ant.Pom.setVersion(Pom.java:570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at
> org.apache.tools.ant.IntrospectionHelper$AttributeSetter.setObject(IntrospectionHelper.java:1498)
> at
> org.apache.tools.ant.IntrospectionHelper.setAttribute(IntrospectionHelper.java:405)
> ... 38 more
> My POM is as follows and has been cut down to show the problem only.
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
> 4.0.0
> MavenAntTest
> MavenAntTest
> 1.0
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.7
>
>
> initialize
>
> xmlns:artifact="antlib:org.apache.maven.artifact.ant">
>
> path="${settings.localRepository}${file.separator}org${file.separator}apache${file.separator}maven${file.separator}maven-ant-tasks${file.separator}2.1.3${file.separator}maven-ant-tasks-2.1.3.jar"
> />
> resource="org/apache/maven/artifact/ant/antlib.xml"
>
> uri="antlib:org.apache.maven.artifact.ant"
> classpathref="maven-ant-tasks.classpath" />
>
[jira] (MANTRUN-174) @ Symbols in path name confusing host resolution.
[ https://jira.codehaus.org/browse/MANTRUN-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307743#comment-307743 ] Darryl L. Miles commented on MANTRUN-174: - Of course it works on its own. But that doesn't necessarily mean the problem is Maven antrun plugin. Have you proof that running the ANT configuration directly in ANT works ? also which version of ANT and its taskdef do you have ? The quoted error indicates that Maven is probably doing the correct thing. It seems to have passed the data through without modification (because it is correctly echoed back in the error message you see). It is also the taskdef in ANT that is ultimately responsible for interpreting the values to pass to the SCP implementation. Please update this bug report if you find that to be the case and lodge the bug with ANT at https://issues.apache.org/bugzilla/buglist.cgi?product=Ant&component=Optional%20Tasks&resolution=--- > @ Symbols in path name confusing host resolution. > - > > Key: MANTRUN-174 > URL: https://jira.codehaus.org/browse/MANTRUN-174 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.7 > Environment: Linux Ubuntu >Reporter: Dave Fennell > > I want to use an SCP target directory that has an "@" in it, like this : > 2011-12-12@15:26:11. > the scp command from effective-pom looks like this (users and passwords > replaced): > todir="user:password@hostname:/project/releases/2011-12-12@15:26:11/mule-3.2.0/apps/" > file="/usr/local/src/project/mule/myapp/target/myapp-1.0-SNAPSHOT.zip" > trust="true" failonerror="true" /> > This results in this slightly odd error: > [ERROR] BUILD ERROR > [INFO] > > [INFO] An Ant BuildException has occured: com.jcraft.jsch.JSchException: > java.net.SocketException: Invalid argument or cannot assign requested address > around Ant part ... todir="user:password@hostname:/project/releases/2011-12-12@15:26:11/mule-3.2.0/apps/" > file="/usr/local/src/project/mule/myapp/target/myapp-1.0-SNAPSHOT.zip" > trust="true" failonerror="true"/>... @ 13:242 in > /usr/local/src/whitelabel/mule/boot-config/target/antrun/build-main.xml > Before that it says: >[scp] Connecting to 15:22 > This should actually say >[scp] Connecting to hostname:22 > This is a problem with the plugin and not scp itself because if I use those > paths directly with SCP on the command line it is fine. from testing it > seems to looks for the LAST match in the line that looks something like > "@[a-z0-8]+:" i.e. between an "@" and a ":" however if there is more than one > match it's probably going to be the first one. -- 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] (MANTRUN-168) Support for setting and overriding value
[ https://jira.codehaus.org/browse/MANTRUN-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Miles updated MANTRUN-168: Attachment: MANTRUN-168.o.a.m.p.mmap.patch @since 1.8 (using Java5 annotations instead of old @javadoc) > Support for setting and overriding value > - > > Key: MANTRUN-168 > URL: https://jira.codehaus.org/browse/MANTRUN-168 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.6 > Environment: All >Reporter: Darryl L. Miles >Priority: Minor > Attachments: MANTRUN-168.o.a.m.p.mmap.patch, o.a.m.p.mmap.patch > > > Have rough patch, am testing and considering unit tests to verify > implementation. -- 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] (MANTRUN-168) Support for setting and overriding value
[ https://jira.codehaus.org/browse/MANTRUN-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=307744#comment-307744 ] Darryl L. Miles edited comment on MANTRUN-168 at 9/4/12 7:07 PM: - NEW PATCH @since 1.8 (using Java5 annotations instead of old @javadoc) was (Author: dlmiles): @since 1.8 (using Java5 annotations instead of old @javadoc) > Support for setting and overriding value > - > > Key: MANTRUN-168 > URL: https://jira.codehaus.org/browse/MANTRUN-168 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.6 > Environment: All >Reporter: Darryl L. Miles >Priority: Minor > Attachments: MANTRUN-168.o.a.m.p.mmap.patch, o.a.m.p.mmap.patch > > > Have rough patch, am testing and considering unit tests to verify > implementation. -- 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-771) release:prepare tries to push tag with invalid Git URL
[
https://jira.codehaus.org/browse/MRELEASE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315010#comment-315010
]
Darryl L. Miles commented on MRELEASE-771:
--
This works for me the element setup with the full
SCM URL including the path part. I have used 2.0 and 2.3.2 version of the
plugin.
> release:prepare tries to push tag with invalid Git URL
> --
>
> Key: MRELEASE-771
> URL: https://jira.codehaus.org/browse/MRELEASE-771
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare, scm
>Affects Versions: 2.3.1
> Environment: Debian 6, run form shell
>Reporter: Tuukka Mustonen
>
> Suddenly, after no version change of maven-release-plugin, our
> {{release:prepare}} started to fail into:
> {noformat}
> [INFO] Unable to tag SCM
> Provider message:
> The git-push command failed.
> Command output:
> ssh: Could not resolve hostname : Name or service not known
> fatal: The remote end hung up unexpectedly
> {noformat}
> The reason appears to be that pushing of the tag uses invalid syntax for git
> command:
> {noformat}
> [INFO] Executing: /bin/sh -c cd "/jenkins/job1" && git push
> ssh://g...@github.mydomain.com myproduct-1.0.0
> {noformat}
> The problem here is that the target URL ({{ssh://g...@github.mydomain.com}})
> is lacking the actual repository identifier
> ({{/MyOrganization/myproduct.git}}) - the plugin is using just
> {{ssh://g...@github.mydomain.com}} while it should be using something like
> {{ssh://g...@github.mydomain.com/MyOrganization/myproduct.git}}.
> I cannot come up with a reason why it started to do this so I cannot give
> instructions on to how to reproduce it either. For us, it occurs in one
> repository, while in another one using the same plugin version and
> configuration the problem doesn't occur.
> Apparently the behavior of using ssh-URL instead of {{origin}} as remote
> repository has been there for ages, added in SCM-498.
--
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-807) Git pushes tag ambigiously
Darryl L. Miles created MRELEASE-807:
Summary: Git pushes tag ambigiously
Key: MRELEASE-807
URL: https://jira.codehaus.org/browse/MRELEASE-807
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, scm
Affects Versions: 2.3.2
Reporter: Darryl L. Miles
Priority: Minor
When the "git push" is run to push the new tag to the repo is uses the
ambigious form of just "root-0.0.1" where ${project.artifactId}=root and
${project.version}=0.0.1
Like this is BAD form:
ssh push ssh://g...@git.domain.com/foobar.git root-0.0.1
This is GOOD form:
ssh push ssh://g...@git.domain.com/foobar.git refs/tags/root-0.0.1
To test this problem out simple create a new branch with the same name as the
tag you are about to use.
git branch root-0.0.1
git push origin root-0.0.1
git branch -av
Now use the maven-release-plugin to try to make a git tag called 'root-0.0.1'.
So it is correct to prefix the tags you push with the "refs/tags/" to that the
repository know you are sending up a tag. This is never ambiguous.
--
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-808) prepare-with-pom needs to be run twice when contains ${project.version}
Darryl L. Miles created MRELEASE-808:
Summary: prepare-with-pom needs to be run twice when
contains ${project.version}
Key: MRELEASE-808
URL: https://jira.codehaus.org/browse/MRELEASE-808
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Darryl L. Miles
Setup your project with a element setup like:
${project.groupId}.${project.artifactId}-${project.version}
Setup ${project.version} to a SNAPSHOT like:
0.0.1-SNAPSHOT
The key thing here is the use of ${project.version} in the and ew
start with a SNAPSHOT version trying to perform a release.
Now we run: mvn release:prepare-with-pom
It will bail out with error now and a message ... "Cannot reliably adjust the
finalName of project:" and I believe this is due to the -SNAPSHOT being visible
and the code that throw the exception is looking at the original, unedited
version of the pom.xml.
I think after editing the pom.xml the in-memory model should be refreshed and
all ${variable} be re-interpreted.
--
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-809) prepare-with-pom deletes release-pom.xml then tries to git add it (presumably so the next commit records the fact)
Darryl L. Miles created MRELEASE-809: Summary: prepare-with-pom deletes release-pom.xml then tries to git add it (presumably so the next commit records the fact) Key: MRELEASE-809 URL: https://jira.codehaus.org/browse/MRELEASE-809 Project: Maven 2.x Release Plugin Issue Type: Bug Components: Git Affects Versions: 2.3.2 Reporter: Darryl L. Miles 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] (MRELEASE-807) Git pushes tag ambigiously
[
https://jira.codehaus.org/browse/MRELEASE-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Miles updated MRELEASE-807:
-
Attachment: 0001-MRELEASE-807-fix-so-that-tags-are-always-pushed-unam.patch
A patch again GIT tree maven-scm.git master c96ca234
> Git pushes tag ambigiously
> --
>
> Key: MRELEASE-807
> URL: https://jira.codehaus.org/browse/MRELEASE-807
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, scm
>Affects Versions: 2.3.2
>Reporter: Darryl L. Miles
>Priority: Minor
> Attachments:
> 0001-MRELEASE-807-fix-so-that-tags-are-always-pushed-unam.patch
>
>
> When the "git push" is run to push the new tag to the repo is uses the
> ambigious form of just "root-0.0.1" where ${project.artifactId}=root and
> ${project.version}=0.0.1
> Like this is BAD form:
> ssh push ssh://g...@git.domain.com/foobar.git root-0.0.1
> This is GOOD form:
> ssh push ssh://g...@git.domain.com/foobar.git refs/tags/root-0.0.1
> To test this problem out simple create a new branch with the same name as the
> tag you are about to use.
> git branch root-0.0.1
> git push origin root-0.0.1
> git branch -av
> Now use the maven-release-plugin to try to make a git tag called 'root-0.0.1'.
> So it is correct to prefix the tags you push with the "refs/tags/" to that
> the repository know you are sending up a tag. This is never ambiguous.
--
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-808) prepare-with-pom needs to be run twice when contains ${project.version}
[
https://jira.codehaus.org/browse/MRELEASE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Miles updated MRELEASE-808:
-
Attachment: 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch
Patch against GIT tree maven-release.git trunk 55dcd08
> prepare-with-pom needs to be run twice when contains
> ${project.version}
> ---
>
> Key: MRELEASE-808
> URL: https://jira.codehaus.org/browse/MRELEASE-808
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Darryl L. Miles
> Attachments:
> 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch
>
>
> Setup your project with a element setup like:
> ${project.groupId}.${project.artifactId}-${project.version}
> Setup ${project.version} to a SNAPSHOT like:
> 0.0.1-SNAPSHOT
> The key thing here is the use of ${project.version} in the and ew
> start with a SNAPSHOT version trying to perform a release.
> Now we run: mvn release:prepare-with-pom
> It will bail out with error now and a message ... "Cannot reliably adjust the
> finalName of project:" and I believe this is due to the -SNAPSHOT being
> visible and the code that throw the exception is looking at the original,
> unedited version of the pom.xml.
> I think after editing the pom.xml the in-memory model should be refreshed and
> all ${variable} be re-interpreted.
--
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-771) release:prepare tries to push tag with invalid Git URL
[
https://jira.codehaus.org/browse/MRELEASE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315022#comment-315022
]
Darryl L. Miles commented on MRELEASE-771:
--
Maybe useful reference for you to verify you are configuring your project
correctly ?
https://maven.apache.org/scm/git.html
There is provision for different fetch/push URLs.
I vote to close this bug and if the problem still exists please ensure to
attach your actual Effective POM of the project that does not work for you so
it can be checked as being a good configuration that should work.
> release:prepare tries to push tag with invalid Git URL
> --
>
> Key: MRELEASE-771
> URL: https://jira.codehaus.org/browse/MRELEASE-771
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare, scm
>Affects Versions: 2.3.1
> Environment: Debian 6, run form shell
>Reporter: Tuukka Mustonen
>
> Suddenly, after no version change of maven-release-plugin, our
> {{release:prepare}} started to fail into:
> {noformat}
> [INFO] Unable to tag SCM
> Provider message:
> The git-push command failed.
> Command output:
> ssh: Could not resolve hostname : Name or service not known
> fatal: The remote end hung up unexpectedly
> {noformat}
> The reason appears to be that pushing of the tag uses invalid syntax for git
> command:
> {noformat}
> [INFO] Executing: /bin/sh -c cd "/jenkins/job1" && git push
> ssh://g...@github.mydomain.com myproduct-1.0.0
> {noformat}
> The problem here is that the target URL ({{ssh://g...@github.mydomain.com}})
> is lacking the actual repository identifier
> ({{/MyOrganization/myproduct.git}}) - the plugin is using just
> {{ssh://g...@github.mydomain.com}} while it should be using something like
> {{ssh://g...@github.mydomain.com/MyOrganization/myproduct.git}}.
> I cannot come up with a reason why it started to do this so I cannot give
> instructions on to how to reproduce it either. For us, it occurs in one
> repository, while in another one using the same plugin version and
> configuration the problem doesn't occur.
> Apparently the behavior of using ssh-URL instead of {{origin}} as remote
> repository has been there for ages, added in SCM-498.
--
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-746) SCM URL being mangled
[ https://jira.codehaus.org/browse/MRELEASE-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315027#comment-315027 ] Darryl L. Miles commented on MRELEASE-746: -- Bug looks bogus please read https://maven.apache.org/scm/git.html Maybe you need: scm:git:git://git@[account].beanstalkapp.com:/[project].git > SCM URL being mangled > - > > Key: MRELEASE-746 > URL: https://jira.codehaus.org/browse/MRELEASE-746 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.2 > Environment: Windows 7 SP1, Java SDK 1.6.0_03, Maven 3.0.4 >Reporter: Logan McGrath >Assignee: Mark Struberg > > When performing mvn release:prepare, the plugin is removing colons from my > GIT URL. My project is hosted on Beanstalk. > Here's the [redacted] URL specified in the POM's SCM element: > git@[account].beanstalkapp.com:/[project].git > Here's the [redacted] URL the plugin ends up using: > git@[account].beanstalkapp.com/[project].git > Notice the missing colon. > The specific error I get using "mvn release:prepare" is: > [ERROR] Provider message: > [ERROR] The git-push command failed. > [ERROR] Command output: > [ERROR] fatal: 'git@[account].beanstalkapp.com/[project].git' does not appear > to be a git repository > [ERROR] fatal: The remote end hung up unexpectedly > Running the command "mvn release:prepare -X" gives me: > Command output: > fatal: 'git@[account].beanstalkapp.com/[project].git' does not appear to be a > git repository > fatal: The remote end hung up unexpectedly > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) > 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) > Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit > files > Provider message: > The git-push command failed. > Command output: > fatal: 'git@[account].beanstalkapp.com/[project].git' does not appear to be a > git repository > fatal: The remote end hung up unexpectedly > at > org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:310) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:258) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException: > Unable to commit files > Provider message: > The git-push command failed. > Command output: > fatal: 'git@[account].beanstalkapp.com/[project].git' does not appear to be a > git repository > fatal: The remote end hung up unexpectedly > at > org.apache.maven.shared.release.phase.AbstractScmCommitPhase.checkin(AbstractScmCommitPhase.java:168) > at > org.apache.maven.shared.release.phase.AbstractScmCommitPhase.performCheckins(AbstractScmCommitPhase.java:148) > at > org.apache.maven.shared.release.phase.ScmCommitPreparationPhase.runLogic(ScmCommitPreparationPhase.java:75) >
[jira] (MRELEASE-801) Wrong value of element from branch
[ https://jira.codehaus.org/browse/MRELEASE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315028#comment-315028 ] Darryl L. Miles commented on MRELEASE-801: -- http://maven.apache.org/pom.html#SCM This is kind of a legacy matter, when the pom.xml was designed git didn't exist. It would be better however if the actual original value was restored, rather than the "effective model" value of "HEAD" when the element was not present before. > Wrong value of element from branch > > > Key: MRELEASE-801 > URL: https://jira.codehaus.org/browse/MRELEASE-801 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch, Git >Affects Versions: 2.3.2 >Reporter: Benson Margulies > > The branch mojo produces HEAD. This can't be right; HEAD isn't the > name of a branch, it's the name of a ref. -- 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-801) Wrong value of element from branch
[ https://jira.codehaus.org/browse/MRELEASE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315029#comment-315029 ] Darryl L. Miles commented on MRELEASE-801: -- The maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java#buildScm(MavenProject) is the location the data is restored. It is not clear how to know if the element was not present before to be able to call scm.setTag(null). > Wrong value of element from branch > > > Key: MRELEASE-801 > URL: https://jira.codehaus.org/browse/MRELEASE-801 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch, Git >Affects Versions: 2.3.2 >Reporter: Benson Margulies > > The branch mojo produces HEAD. This can't be right; HEAD isn't the > name of a branch, it's the name of a ref. -- 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-807) Git pushes tag ambigiously
[
https://jira.codehaus.org/browse/MRELEASE-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Miles updated MRELEASE-807:
-
Attachment: 0002-MRELEASE-807-also-disambiguate-push-commands-when-cr.patch
Another patch to apply AS WELL AS the 1st patch.
GIT tree maven-scm.git master c96ca234
This addresses a similar matter in respect of creating new branches on the
remote system. Without the patch a conflict may occur of a branch and a tag
share the same name. With this patch we are being very clear to the server
what the intention is, i.e. to work with branches (not with tags).
See the other patch file for when we want to work with tags (not with branches).
> Git pushes tag ambigiously
> --
>
> Key: MRELEASE-807
> URL: https://jira.codehaus.org/browse/MRELEASE-807
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, scm
>Affects Versions: 2.3.2
>Reporter: Darryl L. Miles
>Priority: Minor
> Attachments:
> 0001-MRELEASE-807-fix-so-that-tags-are-always-pushed-unam.patch,
> 0002-MRELEASE-807-also-disambiguate-push-commands-when-cr.patch
>
>
> When the "git push" is run to push the new tag to the repo is uses the
> ambigious form of just "root-0.0.1" where ${project.artifactId}=root and
> ${project.version}=0.0.1
> Like this is BAD form:
> ssh push ssh://g...@git.domain.com/foobar.git root-0.0.1
> This is GOOD form:
> ssh push ssh://g...@git.domain.com/foobar.git refs/tags/root-0.0.1
> To test this problem out simple create a new branch with the same name as the
> tag you are about to use.
> git branch root-0.0.1
> git push origin root-0.0.1
> git branch -av
> Now use the maven-release-plugin to try to make a git tag called 'root-0.0.1'.
> So it is correct to prefix the tags you push with the "refs/tags/" to that
> the repository know you are sending up a tag. This is never ambiguous.
--
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-808) prepare-with-pom needs to be run twice when contains ${project.version}
[
https://jira.codehaus.org/browse/MRELEASE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315108#comment-315108
]
Darryl L. Miles commented on MRELEASE-808:
--
Test might succeed but does it relate to the problem ?
I have been using 2.3.2 also scm:git: also shouldn't the output version be
0.0.1, shouldn't the output effective pom.xml not include any ${variables} ?
Indeed this is the nature of the problem, the in memory model of the pom.xml is
copied the project.version changed and the variables not reinterpreted.
What is most important is if the plugin works for real (certainly for the
source tree my commit is based on '55dcd08' it did not work for real). So
before my patch is doesn't work after my patch it does work, this has been
tested by me.
I shall see if I can update and run your new test and then try each of these
these things. But I suspect the new test does not touch the problem. Maybe
that is why it passes without needing my patch.
> prepare-with-pom needs to be run twice when contains
> ${project.version}
> ---
>
> Key: MRELEASE-808
> URL: https://jira.codehaus.org/browse/MRELEASE-808
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Darryl L. Miles
> Attachments:
> 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch
>
>
> Setup your project with a element setup like:
> ${project.groupId}.${project.artifactId}-${project.version}
> Setup ${project.version} to a SNAPSHOT like:
> 0.0.1-SNAPSHOT
> The key thing here is the use of ${project.version} in the and ew
> start with a SNAPSHOT version trying to perform a release.
> Now we run: mvn release:prepare-with-pom
> It will bail out with error now and a message ... "Cannot reliably adjust the
> finalName of project:" and I believe this is due to the -SNAPSHOT being
> visible and the code that throw the exception is looking at the original,
> unedited version of the pom.xml.
> I think after editing the pom.xml the in-memory model should be refreshed and
> all ${variable} be re-interpreted.
--
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-808) prepare-with-pom needs to be run twice when contains ${project.version}
[
https://jira.codehaus.org/browse/MRELEASE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315112#comment-315112
]
Darryl L. Miles commented on MRELEASE-808:
--
Your change has not showed up in git at http://git.apache.org/maven-scm.git
yet. Until it does I can not begin testing (as I lost patience for SVN
sometime ago :) and will only use it when paid to do so)
> prepare-with-pom needs to be run twice when contains
> ${project.version}
> ---
>
> Key: MRELEASE-808
> URL: https://jira.codehaus.org/browse/MRELEASE-808
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Darryl L. Miles
> Attachments:
> 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch
>
>
> Setup your project with a element setup like:
> ${project.groupId}.${project.artifactId}-${project.version}
> Setup ${project.version} to a SNAPSHOT like:
> 0.0.1-SNAPSHOT
> The key thing here is the use of ${project.version} in the and ew
> start with a SNAPSHOT version trying to perform a release.
> Now we run: mvn release:prepare-with-pom
> It will bail out with error now and a message ... "Cannot reliably adjust the
> finalName of project:" and I believe this is due to the -SNAPSHOT being
> visible and the code that throw the exception is looking at the original,
> unedited version of the pom.xml.
> I think after editing the pom.xml the in-memory model should be refreshed and
> all ${variable} be re-interpreted.
--
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-808) prepare-with-pom needs to be run twice when contains ${project.version}
[
https://jira.codehaus.org/browse/MRELEASE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Miles updated MRELEASE-808:
-
Attachment: 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch
UPDATED PATCH
This replaces the existing patch.
Patch against GIT tree maven-release.git trunk 55dcd08
This add checking/protection from other use since the previous version pf the
patch, this version protects against cases where projectVersion="1" and
releaseVersion="2" this is why it was considered unsafe before.
The most ideal patch would be to have the newly constructed MavenProject model
in memory go back to the original ${variable} and reinterpret the variable in
the context of the new in-memory model and then set the finalName field to the
new value.
But for now this patch fixes the problem for me and should provide protection
against editing the value incorrectly in other cases.
> prepare-with-pom needs to be run twice when contains
> ${project.version}
> ---
>
> Key: MRELEASE-808
> URL: https://jira.codehaus.org/browse/MRELEASE-808
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Darryl L. Miles
> Attachments:
> 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch,
> 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch
>
>
> Setup your project with a element setup like:
> ${project.groupId}.${project.artifactId}-${project.version}
> Setup ${project.version} to a SNAPSHOT like:
> 0.0.1-SNAPSHOT
> The key thing here is the use of ${project.version} in the and ew
> start with a SNAPSHOT version trying to perform a release.
> Now we run: mvn release:prepare-with-pom
> It will bail out with error now and a message ... "Cannot reliably adjust the
> finalName of project:" and I believe this is due to the -SNAPSHOT being
> visible and the code that throw the exception is looking at the original,
> unedited version of the pom.xml.
> I think after editing the pom.xml the in-memory model should be refreshed and
> all ${variable} be re-interpreted.
--
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-808) prepare-with-pom needs to be run twice when contains ${project.version}
[
https://jira.codehaus.org/browse/MRELEASE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315155#comment-315155
]
Darryl L. Miles commented on MRELEASE-808:
--
I can confirm that testing with the unit test (this PASSES) but without any
version of my patch fails to process a real release run with the following
command line:
mvn -X -DignoreSnapshots=true release:prepare-with-pom
With my patch it works as expected with 2 new commits generated with correct
information.
The reason for using -DignoreSnapshots=true is because I am using the version
of the plugin and its dependency from my local M2 repository with the following
configuration:
org.apache.maven.plugins
maven-release-plugin
2.4-SNAPSHOT
org.apache.maven.scm
maven-scm-providers-standard
1.9-SNAPSHOT
pom
org.apache.maven.scm
maven-scm-provider-gitexe
1.9-SNAPSHOT
org.apache.maven.scm
maven-scm-api
1.9-SNAPSHOT
org.apache.maven.release
maven-release-manager
2.4-SNAPSHOT
> prepare-with-pom needs to be run twice when contains
> ${project.version}
> ---
>
> Key: MRELEASE-808
> URL: https://jira.codehaus.org/browse/MRELEASE-808
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Darryl L. Miles
> Attachments:
> 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch,
> 0001-MRELEASE-808-Allow-fixup-of-SNAPSHOT-version-in-fina.patch
>
>
> Setup your project with a element setup like:
> ${project.groupId}.${project.artifactId}-${project.version}
> Setup ${project.version} to a SNAPSHOT like:
> 0.0.1-SNAPSHOT
> The key thing here is the use of ${project.version} in the and ew
> start with a SNAPSHOT version trying to perform a release.
> Now we run: mvn release:prepare-with-pom
> It will bail out with error now and a message ... "Cannot reliably adjust the
> finalName of project:" and I believe this is due to the -SNAPSHOT being
> visible and the code that throw the exception is looking at the original,
> unedited version of the pom.xml.
> I think after editing the pom.xml the in-memory model should be refreshed and
> all ${variable} be re-interpreted.
--
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-746) SCM URL being mangled
[
https://jira.codehaus.org/browse/MRELEASE-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315156#comment-315156
]
Darryl L. Miles commented on MRELEASE-746:
--
So you are saying this is a problem with beanstalk ? and this ticket can be
closed as not a bug in Maven ?
> SCM URL being mangled
> -
>
> Key: MRELEASE-746
> URL: https://jira.codehaus.org/browse/MRELEASE-746
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.2.2
> Environment: Windows 7 SP1, Java SDK 1.6.0_03, Maven 3.0.4
>Reporter: Logan McGrath
>Assignee: Mark Struberg
>
> When performing {{mvn release:prepare}}, the plugin is removing colons from
> my GIT URL. My project is hosted on Beanstalk.
> Here's the [redacted] URL specified in the POM's SCM element:
> git@[account].beanstalkapp.com:/[project].git
> Here's the [redacted] URL the plugin ends up using:
> git@[account].beanstalkapp.com/[project].git
> Notice the missing colon.
> The specific error I get using {{mvn release:prepare}} is:
> {noformat}
> [ERROR] Provider message:
> [ERROR] The git-push command failed.
> [ERROR] Command output:
> [ERROR] fatal: 'git@[account].beanstalkapp.com/[project].git' does not appear
> to be a git repository
> [ERROR] fatal: The remote end hung up unexpectedly
> {noformat}
> Running the command {{mvn release:prepare -X}} gives me:
> Command output:
> {noformat}
> fatal: 'git@[account].beanstalkapp.com/[project].git' does not appear to be a
> git repository
> fatal: The remote end hung up unexpectedly
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> 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)
> Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit
> files
> Provider message:
> The git-push command failed.
> Command output:
> fatal: 'git@[account].beanstalkapp.com/[project].git' does not appear to be a
> git repository
> fatal: The remote end hung up unexpectedly
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:310)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:258)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException:
> Unable to commit files
> Provider message:
> The git-push command failed.
> Command output:
> fatal: 'git@[account].beanstalkapp.com/[project].git' does not appear to be a
> git repository
> fatal: The remote end hung up unexpectedly
> at
> org.apache.maven.shared.release.phase.AbstractScmCommitPhase.checkin(AbstractScmCommitPhase.java:168)
> at
> org.apache.maven.shared.release.phase.AbstractScmCommitPhase.performCheckins(AbstractScmCommitPhase.java:148)
> at
> org.apache.maven.shared.release.phase.ScmCommitPreparationPhase.runLogic(ScmCommitPreparationPhase.jav
[jira] (MRELEASE-809) 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/MRELEASE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Miles updated MRELEASE-809: - Attachment: 0001-MRELEASE-809-Use-git-correctly-when-removing-and-add.patch Patch in git format against maven-scm.git master c96ca24 The code in the CheckIn operation the patch sources could be improved as it does two "git status --porcelain" during the check-in operation. Maybe these could merged into the 'git status' I now perform. This patch also make an API public this follows the same design as the Bazaar plugin uses. > prepare-with-pom deletes release-pom.xml then tries to git add it (presumably > so the next commit records the fact) > -- > > Key: MRELEASE-809 > URL: https://jira.codehaus.org/browse/MRELEASE-809 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2 >Reporter: Darryl L. Miles > 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] (MRELEASE-809) 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/MRELEASE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315157#comment-315157 ] Darryl L. Miles edited comment on MRELEASE-809 at 12/6/12 11:17 AM: Patch in git format against maven-scm.git master c96ca24 The code in the CheckIn operation the patch touches could be improved as it does two "git status --porcelain" during the check-in operation. Maybe these could merged into the 'git status' I now perform. This patch also make an API public this follows the same design as the Bazaar plugin uses. was (Author: dlmiles): Patch in git format against maven-scm.git master c96ca24 The code in the CheckIn operation the patch sources could be improved as it does two "git status --porcelain" during the check-in operation. Maybe these could merged into the 'git status' I now perform. This patch also make an API public this follows the same design as the Bazaar plugin uses. > prepare-with-pom deletes release-pom.xml then tries to git add it (presumably > so the next commit records the fact) > -- > > Key: MRELEASE-809 > URL: https://jira.codehaus.org/browse/MRELEASE-809 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2 >Reporter: Darryl L. Miles > 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] (MRELEASE-809) 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/MRELEASE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315173#comment-315173 ] Darryl L. Miles commented on MRELEASE-809: -- Possible duplicate of MRELEASE-539 ??? But patch provided here. > prepare-with-pom deletes release-pom.xml then tries to git add it (presumably > so the next commit records the fact) > -- > > Key: MRELEASE-809 > URL: https://jira.codehaus.org/browse/MRELEASE-809 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2 >Reporter: Darryl L. Miles > 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] (MRELEASE-539) prepare-with-pom fails for git provider
[
https://jira.codehaus.org/browse/MRELEASE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315172#comment-315172
]
Darryl L. Miles commented on MRELEASE-539:
--
also reported in MRELEASE-809 with patch provided there.
> prepare-with-pom fails for git provider
> ---
>
> Key: MRELEASE-539
> URL: https://jira.codehaus.org/browse/MRELEASE-539
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare-with-pom
>Affects Versions: 2.0
>Reporter: Maarten Billemont
>
> When running the release-with-pom goal; toward the end, the release-poms are
> deleted and this change is committed. Unfortunately, with the GIT provider,
> this is done by first git rm'ing the files and then git add'ing them
> (presumably, to add the rm change to the index). The latter fails because
> the files are no longer present.
> {code}
> [INFO] Executing: /bin/sh -c cd /Users/lhunath/work/git && git rm
> release-pom.xml d/release-pom.xml c/release-pom.xml e/release-pom.xml
> [INFO] Working directory: /Users/lhunath/work/git
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /Users/lhunath/work/git && git add -- pom.xml
> release-pom.xml d/pom.xml d/release-pom.xml c/pom.xml c/release-pom.xml
> e/pom.xml e/release-pom.xml
> [INFO] Working directory: /Users/lhunath/work/git
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to commit files
> Provider message:
> The git-add command failed.
> Command output:
> fatal: pathspec 'release-pom.xml' did not match any files
> {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-801) Wrong value of element from branch
[ https://jira.codehaus.org/browse/MRELEASE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Miles updated MRELEASE-801: - Attachment: 0001-MRELEASE-801-don-t-use-scm.tag-HEAD-for-GIT-provider.patch Patch to GIT maven-release.git trunk a603d07 This patch copies what CVS does in the situation. > Wrong value of element from branch > > > Key: MRELEASE-801 > URL: https://jira.codehaus.org/browse/MRELEASE-801 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch, Git >Affects Versions: 2.3.2 >Reporter: Benson Margulies > Attachments: > 0001-MRELEASE-801-don-t-use-scm.tag-HEAD-for-GIT-provider.patch > > > The branch mojo produces HEAD. This can't be right; HEAD isn't the > name of a branch, it's the name of a ref. -- 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-810) When running ScmCommitDevelopmentPhase the wrong version is presented to the commit log
Darryl L. Miles created MRELEASE-810:
Summary: When running ScmCommitDevelopmentPhase the wrong version
is presented to the commit log
Key: MRELEASE-810
URL: https://jira.codehaus.org/browse/MRELEASE-810
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Darryl L. Miles
Priority: Minor
When running ScmCommitDevelopmentPhase the wrong version is presented to the
commit log
When trying to get the default new development commit message to read:
[maven-release-plugin] prepare for next development iteration 0.0.2-SNAPSHOT
The default message does not use {0} even though a parameter is presented. I
suspect {0} was not used as it was the wrong version number and no one bothered
to fix it.
--
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-810) When running ScmCommitDevelopmentPhase the wrong version is presented to the commit log
[
https://jira.codehaus.org/browse/MRELEASE-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Miles updated MRELEASE-810:
-
Attachment: 0001-MRELEASE-810-ScmCommitDevelopmentPhase-include-SNAPS.patch
Patch on git tree maven-release.git trunk a603d07
> When running ScmCommitDevelopmentPhase the wrong version is presented to the
> commit log
> ---
>
> Key: MRELEASE-810
> URL: https://jira.codehaus.org/browse/MRELEASE-810
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Darryl L. Miles
>Priority: Minor
> Attachments:
> 0001-MRELEASE-810-ScmCommitDevelopmentPhase-include-SNAPS.patch
>
>
> When running ScmCommitDevelopmentPhase the wrong version is presented to the
> commit log
> When trying to get the default new development commit message to read:
> [maven-release-plugin] prepare for next development iteration 0.0.2-SNAPSHOT
> The default message does not use {0} even though a parameter is presented. I
> suspect {0} was not used as it was the wrong version number and no one
> bothered to fix it.
--
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-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315231#comment-315231 ] Darryl L. Miles commented on MRELEASE-780: -- How do you mean exactly ? You are speaking about a release that is made when a tag is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.3.2 >Reporter: E > > If you create an release from the branch there should be no commits on the > tag-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] (MRELEASE-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315231#comment-315231 ] Darryl L. Miles edited comment on MRELEASE-780 at 12/7/12 10:50 AM: How do you mean exactly ? You are speaking about a release that is made when a tag is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic doing one or more commits for code changes, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. was (Author: dlmiles): How do you mean exactly ? You are speaking about a release that is made when a tag is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.3.2 >Reporter: E > > If you create an release from the branch there should be no commits on the > tag-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] (MRELEASE-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315231#comment-315231 ] Darryl L. Miles edited comment on MRELEASE-780 at 12/7/12 10:53 AM: How do you mean exactly ? You are speaking about a release that is made and a tag for that release is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic doing one or more commits for code changes, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. was (Author: dlmiles): How do you mean exactly ? You are speaking about a release that is made when a tag is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic doing one or more commits for code changes, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.3.2 >Reporter: E > > If you create an release from the branch there should be no commits on the > tag-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-705) Git pushes tag ambigiously
[
https://jira.codehaus.org/browse/SCM-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Miles updated SCM-705:
Attachment: 0003-MRELEASE-807-also-disambiguate-push-commands-when-cr.patch
A 3rd patch to apply AS WELL AS the other 2 patches for another location that
can be disambiguated.
> Git pushes tag ambigiously
> --
>
> Key: SCM-705
> URL: https://jira.codehaus.org/browse/SCM-705
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8.1
>Reporter: Darryl L. Miles
>Priority: Minor
> Attachments:
> 0001-MRELEASE-807-fix-so-that-tags-are-always-pushed-unam.patch,
> 0002-MRELEASE-807-also-disambiguate-push-commands-when-cr.patch,
> 0003-MRELEASE-807-also-disambiguate-push-commands-when-cr.patch
>
>
> When the "git push" is run to push the new tag to the repo is uses the
> ambigious form of just "root-0.0.1" where ${project.artifactId}=root and
> ${project.version}=0.0.1
> Like this is BAD form:
> ssh push ssh://g...@git.domain.com/foobar.git root-0.0.1
> This is GOOD form:
> ssh push ssh://g...@git.domain.com/foobar.git refs/tags/root-0.0.1
> To test this problem out simple create a new branch with the same name as the
> tag you are about to use.
> git branch root-0.0.1
> git push origin root-0.0.1
> git branch -av
> Now use the maven-release-plugin to try to make a git tag called 'root-0.0.1'.
> So it is correct to prefix the tags you push with the "refs/tags/" to that
> the repository know you are sending up a tag. This is never ambiguous.
--
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-5249) inherit scm in superPom
[
https://jira.codehaus.org/browse/MNG-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315315#comment-315315
]
Darryl L. Miles commented on MNG-5249:
--
This convention is not documented (or useful for non SVN / Apache Foundation
remote SCM system setups). I would expect this to be documented here
https://maven.apache.org/pom.html#SCM
It would be useful to remove the convention of appending the "/${parent.name}"
value onto the end of the elements for URLs such as
and .
Instead have Maven configure a system variable like ${maven.scm.path} which
would be "/parent-parent/parent" in the case where we have foobar:project
inherit from foobar:parent inherit from foobar:parent-parent which has
elements configured. This way when compatibility is broken in some future
release those users wishing to keep the old behaviour only need to add
${maven.scm.path} to the end of their URLs (in their equivalent
foobar:parent-parent pom.xml)
> inherit scm in superPom
> ---
>
> Key: MNG-5249
> URL: https://jira.codehaus.org/browse/MNG-5249
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: Issues to be reviewed for 3.x
> Environment: maven 3.0.3
>Reporter: Jose Manuel Prieto
>
> It's similar to http://jira.codehaus.org/browse/MNG-2006 but with GIT.
> Show too:
> http://mail-archives.apache.org/mod_mbox/maven-users/201202.mbox/%3CCAAUMjNbO_o4WhwTvGoZueVLsaM5XULczdrp%3D9eioMV2YH9gk1A%40mail.gmail.com%3E
> and reponses into maven user lists
--
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-331) SCM urls are broken for all modules, except the parent
[ https://jira.codehaus.org/browse/MRELEASE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315316#comment-315316 ] Darryl L. Miles commented on MRELEASE-331: -- One possible workaround is to try adding a "#" to end of the text in the super POM that sets the URL elements. This causes the unwanted appended part to become a URL fragment. You maybe lucky enough that your SCM provider ignores URL fragments. > SCM urls are broken for all modules, except the parent > --- > > Key: MRELEASE-331 > URL: https://jira.codehaus.org/browse/MRELEASE-331 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 >Reporter: Vincent Siveton >Priority: Blocker > Labels: scrub-review-started > > This comes from the parent pom, which is missing a / at the end of the scm > urls. > See: > http://www.nabble.com/Re%3A-svn-commit%3A-r635240---in--maven-plugin-tools-trunk%3A-.--maven-plugin-plugin--maven-plugin-tools-ant--maven-plugin-tools-api--maven-plugin-tools-beanshell--maven-plugin-tools-java--maven-plugin-tools-javadoc--maven-plugin-tools-model--tt15929761s177.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-4508) No way to avoid adding artifactId to site urls
[
https://jira.codehaus.org/browse/MNG-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315317#comment-315317
]
Darryl L. Miles commented on MNG-4508:
--
Remove the inheritance rules but provide a maven configured variable
${maven.project.path} or something that will becomes "/parent-parent/parent" in
deepest level of a 3 level project. The super POM will be an empty string.
The mid-level will be "/parent-parent". Now users get the best of both worlds
without being chained to the convention.
> No way to avoid adding artifactId to site urls
> --
>
> Key: MNG-4508
> URL: https://jira.codehaus.org/browse/MNG-4508
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Richard van der Hoff
>Priority: Minor
> Fix For: 3.2
>
>
> Currently, whenever a child pom inherits from a parent (and doesn't override
> the relevant settings), both project.url and
> project.distributionManagement.site.url have the name of the child artifact
> appended.
> It would be nice to be able to have something like
> :code:
> scpexe://host/blah/${project.artifactId}/${project.version}
> :code:
> and have this inherited to all child poms in the obvious way.
> My usecase for this is that we have a single parent pom for all our projects,
> with useful settings such as distributionManagement, and I'd like to be able
> to deploy their sites to a single directory and have Apache generate me a
> directory listing for all the child projects. However, I curently have no way
> of releasing the parent project without obliterating the list of child
> projects.
--
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-771) release:prepare tries to push tag with invalid Git URL
[
https://jira.codehaus.org/browse/MRELEASE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315376#comment-315376
]
Darryl L. Miles commented on MRELEASE-771:
--
Related MRELEASE-767 ? The original reporter did not convey the hierarchical
organization of the projects he has. I would guess the affected project is one
or two levels down in module hierarchy.
> release:prepare tries to push tag with invalid Git URL
> --
>
> Key: MRELEASE-771
> URL: https://jira.codehaus.org/browse/MRELEASE-771
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare, scm
>Affects Versions: 2.3.1
> Environment: Debian 6, run form shell
>Reporter: Tuukka Mustonen
>
> Suddenly, after no version change of maven-release-plugin, our
> {{release:prepare}} started to fail into:
> {noformat}
> [INFO] Unable to tag SCM
> Provider message:
> The git-push command failed.
> Command output:
> ssh: Could not resolve hostname : Name or service not known
> fatal: The remote end hung up unexpectedly
> {noformat}
> The reason appears to be that pushing of the tag uses invalid syntax for git
> command:
> {noformat}
> [INFO] Executing: /bin/sh -c cd "/jenkins/job1" && git push
> ssh://g...@github.mydomain.com myproduct-1.0.0
> {noformat}
> The problem here is that the target URL ({{ssh://g...@github.mydomain.com}})
> is lacking the actual repository identifier
> ({{/MyOrganization/myproduct.git}}) - the plugin is using just
> {{ssh://g...@github.mydomain.com}} while it should be using something like
> {{ssh://g...@github.mydomain.com/MyOrganization/myproduct.git}}.
> I cannot come up with a reason why it started to do this so I cannot give
> instructions on to how to reproduce it either. For us, it occurs in one
> repository, while in another one using the same plugin version and
> configuration the problem doesn't occur.
> Apparently the behavior of using ssh-URL instead of {{origin}} as remote
> repository has been there for ages, added in SCM-498.
--
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-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315682#comment-315682 ] Darryl L. Miles commented on MRELEASE-780: -- Can everyone with an interest in this ticket declare their SCM provider type ? svn ? git ? they work differently and the original code has an SVN bias. I see Michael Wenig only references SVN so I take it to be the provider. Also that if an SCM provider allows modification of a tag (as a feature of that system) then if users of that SCM provider need to enforce a 'can not change tag revision policy' it should always be enforced by the server. You should treat this as a feature of the SCM provider you need to disable for your use case. This is just stated to reinforce whose responsibility it is to enforce such a policy. This has no effect on making the Maven release plugin better i.e. while I may not fully understand the nature of what is being explained (because I have yet to sit down and repeat the sequence and examine the behaviour described first hand). I think this bug is a duplicate of other bug numbers reporting the same matter. The current workflow inside maven-release-plugin is: maven-release-manager/src/main/components-fragment.xml: rewrite-poms-for-branch scm-commit-branch scm-branch But I propose there should be: rewrite-poms-for-branch scm-branch-prepare scm-commit-branch scm-branch I am slowly working on this idea for GIT SCM provider as I had presumed that other SCM providers needed the sequence to be the other way around. That being SVN needed it. However in light of this explanation what would the repercussions of simply switching around the order of the 2 states: scm-commit-branch AND scm-branch ? Without me working on adding a new state 'scm-branch-prepare' So the really important question is exactly what SCM provider needs the phase order as they are right now ? > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.3.2 >Reporter: E > > If you create an release from the branch there should be no commits on the > tag-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] (MRELEASE-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315682#comment-315682 ] Darryl L. Miles edited comment on MRELEASE-780 at 12/14/12 3:18 AM: Can everyone with an interest in this ticket declare their SCM provider type ? svn ? git ? they work differently and the original code has an SVN bias. I see Michael Wenig only references SVN so I take it to be the provider. Also that if an SCM provider allows modification of a tag (as a feature of that system) then if users of that SCM provider need to enforce a 'can not change tag revision policy' it should always be enforced by the server. You should treat this as a feature of the SCM provider you need to disable for your use case. This is just stated to reinforce whose responsibility it is to enforce such a policy. This has no effect on making the Maven release plugin better i.e. while I may not fully understand the nature of what is being explained (because I have yet to sit down and repeat the sequence and examine the behaviour described first hand). I think this bug is a duplicate of other bug numbers reporting the same matter. The current workflow inside maven-release-plugin is: maven-release-manager/src/main/components-fragment.xml: rewrite-poms-for-branch scm-commit-branch scm-branch But I propose there should be: rewrite-poms-for-branch scm-branch-prepare scm-commit-branch scm-branch I am slowly working on this idea for GIT SCM provider as I had presumed that other SCM providers needed the sequence to be the other way around. That being SVN needed it. However in light of this explanation what would the repercussions of simply switching around the order of the 2 states: scm-commit-branch AND scm-branch ? Without me working on adding a new state 'scm-branch-prepare' So the really important question is exactly what SCM provider needs the phase order as they are right now ? was (Author: dlmiles): Can everyone with an interest in this ticket declare their SCM provider type ? svn ? git ? they work differently and the original code has an SVN bias. I see Michael Wenig only references SVN so I take it to be the provider. Also that if an SCM provider allows modification of a tag (as a feature of that system) then if users of that SCM provider need to enforce a 'can not change tag revision policy' it should always be enforced by the server. You should treat this as a feature of the SCM provider you need to disable for your use case. This is just stated to reinforce whose responsibility it is to enforce such a policy. This has no effect on making the Maven release plugin better i.e. while I may not fully understand the nature of what is being explained (because I have yet to sit down and repeat the sequence and examine the behaviour described first hand). I think this bug is a duplicate of other bug numbers reporting the same matter. The current workflow inside maven-release-plugin is: maven-release-manager/src/main/components-fragment.xml: rewrite-poms-for-branch scm-commit-branch scm-branch But I propose there should be: rewrite-poms-for-branch scm-branch-prepare scm-commit-branch scm-branch I am slowly working on this idea for GIT SCM provider as I had presumed that other SCM providers needed the sequence to be the other way around. That being SVN needed it. However in light of this explanation what would the repercussions of simply switching around the order of the 2 states: scm-commit-branch AND scm-branch ? Without me working on adding a new state 'scm-branch-prepare' So the really important question is exactly what SCM provider needs the phase order as they are right now ? > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.3.2 >Reporter: E > > If you create an release from the branch there should be no commits on the > tag-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] (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ https://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315683#comment-315683 ] Darryl L. Miles commented on MRELEASE-594: -- => I cleary see it as a bug, that the release has been possible. Without some kind of command line / property override you mean ? Ideally the override for different things: * SNAPSHOT parent/grand-parents [parent] * SNAPSHOT plugins versions used [plugin] * SNAPSHOT dependency versions used [dependency] * SNAPSHOT the project(s) being the subject release itself [project] I see all 4 are being separate matters but maybe sharing a single property override to allow release to happen. With a string so an override might look like: mvn release:foo -DallowSnapshotVersionInRelease=parent,plugin,dependency,project,all The idea of not using an all or nothing (which is probe to human error) it to make the person think a little bit more as quite often I want to allow a plugin or dependency to be a SNAPSHOT but never my own projects and their parents. Also all error/warning dialogs should indicate the nature of the SNAPSHOT i.e. what category from the above is it in and suggest the option to the use to retry the release with the property set. > release:prepare should stop when there is snapshots in dependencies management > -- > > Key: MRELEASE-594 > URL: https://jira.codehaus.org/browse/MRELEASE-594 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Reporter: Thomas Bruyelle >Assignee: Olivier Lamy > Fix For: Backlog > > -- 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-594) release:prepare should stop when there is snapshots in dependencies management
[ https://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315683#comment-315683 ] Darryl L. Miles edited comment on MRELEASE-594 at 12/14/12 3:34 AM: => I cleary see it as a bug, that the release has been possible. Without some kind of command line / property override you mean ? Ideally the override for different things: * SNAPSHOT parent/grand-parents [parent] * SNAPSHOT plugins versions used [plugin] * SNAPSHOT dependency versions used [dependency] * SNAPSHOT the project(s) being the subject release itself [project] I see all 4 are being separate matters but maybe sharing a single property override to allow release to happen. With a string so an override might look like: mvn release:foo -DallowSnapshotVersionInRelease=parent,plugin,dependency,project,all The idea of not using an all or nothing (which is prone to human error). The option should make the person think a little bit more about it and the solution should not be a sledgehammer but the minimum surface area of overriding the normal rules required to push past the problem. As quite often I want to allow a plugin or dependency to be a SNAPSHOT (I have no control of their versions sometimes) but never my own projects and their parents. Also all error/warning dialogs should indicate the nature of the SNAPSHOT i.e. what category from the above is it in and suggest the minimum amount of override with property to use when retrying the release. i.e. don't offer "all" but something else. was (Author: dlmiles): => I cleary see it as a bug, that the release has been possible. Without some kind of command line / property override you mean ? Ideally the override for different things: * SNAPSHOT parent/grand-parents [parent] * SNAPSHOT plugins versions used [plugin] * SNAPSHOT dependency versions used [dependency] * SNAPSHOT the project(s) being the subject release itself [project] I see all 4 are being separate matters but maybe sharing a single property override to allow release to happen. With a string so an override might look like: mvn release:foo -DallowSnapshotVersionInRelease=parent,plugin,dependency,project,all The idea of not using an all or nothing (which is probe to human error) it to make the person think a little bit more as quite often I want to allow a plugin or dependency to be a SNAPSHOT but never my own projects and their parents. Also all error/warning dialogs should indicate the nature of the SNAPSHOT i.e. what category from the above is it in and suggest the option to the use to retry the release with the property set. > release:prepare should stop when there is snapshots in dependencies management > -- > > Key: MRELEASE-594 > URL: https://jira.codehaus.org/browse/MRELEASE-594 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Reporter: Thomas Bruyelle >Assignee: Olivier Lamy > Fix For: Backlog > > -- 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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315687#comment-315687
]
Darryl L. Miles commented on MANTRUN-177:
-
A quick look from my point of view you are setting the property:
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering.
Why don't you setup a pom.xml section:
../foobar
and remove the element from the antrun configuration ? what
would be wrong with that ? the path being used it setup is still configured in
the same pom.xml file.
The only new thing that would happen is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on sections.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315687#comment-315687
]
Darryl L. Miles edited comment on MANTRUN-177 at 12/14/12 3:46 AM:
---
A quick look from my point of view you are setting the property:
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering.
Why don't you setup a pom.xml section:
../filters/filters.pc.properties
and remove the element from the antrun configuration
completely ? what would be wrong with that ? the path being used is setup is
still configured in the same pom.xml file.
The only side-effect I can think up is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on sections. Or simply use a name that will never clash change
'filter.file' for 'local.project.foobar.filter.file'
was (Author: dlmiles):
A quick look from my point of view you are setting the property:
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering.
Why don't you setup a pom.xml section:
../foobar
and remove the element from the antrun configuration ? what
would be wrong with that ? the path being used it setup is still configured in
the same pom.xml file.
The only new thing that would happen is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on sections.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315687#comment-315687
]
Darryl L. Miles edited comment on MANTRUN-177 at 12/14/12 3:46 AM:
---
A quick look from my point of view you are setting the property:
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering.
Why don't you setup a pom.xml section:
../filters/filters.pc.properties
and remove the element from the antrun configuration
completely ? what would be wrong with that ? the path being used is setup is
still configured in the same pom.xml file.
The only side-effect I can think up is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on sections. Or simply use a name that will never clash change
'filter.file' for 'local.project.abc.efg.filter.file'
was (Author: dlmiles):
A quick look from my point of view you are setting the property:
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering.
Why don't you setup a pom.xml section:
../filters/filters.pc.properties
and remove the element from the antrun configuration
completely ? what would be wrong with that ? the path being used is setup is
still configured in the same pom.xml file.
The only side-effect I can think up is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on sections. Or simply use a name that will never clash change
'filter.file' for 'local.project.foobar.filter.file'
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315687#comment-315687
]
Darryl L. Miles edited comment on MANTRUN-177 at 12/14/12 3:50 AM:
---
A quick look from my point of view you are setting the property:
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering. You
have only configured the property at a lower (more nested) scope than the place
where it is being used. Each plugin has its own scope the is
used by antrun/ANT not by maven.
Why don't you setup a pom.xml section:
../filters/filters.pc.properties
and remove the element from the antrun configuration
completely ? what would be wrong with that ? the path being used is setup is
still configured in the same pom.xml file.
The only side-effect I can think up is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on sections. Or simply use a name that will never clash change
'filter.file' for 'local.project.abc.efg.filter.file'
was (Author: dlmiles):
A quick look from my point of view you are setting the property:
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering.
Why don't you setup a pom.xml section:
../filters/filters.pc.properties
and remove the element from the antrun configuration
completely ? what would be wrong with that ? the path being used is setup is
still configured in the same pom.xml file.
The only side-effect I can think up is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on sections. Or simply use a name that will never clash change
'filter.file' for 'local.project.abc.efg.filter.file'
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles edited comment on MANTRUN-177 at 1/2/13 9:52 PM:
-
'# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
'# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
was (Author: dlmiles):
`# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
`# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles edited comment on MANTRUN-177 at 1/2/13 9:52 PM:
-
`# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
`# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
was (Author: dlmiles):
# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles edited comment on MANTRUN-177 at 1/2/13 9:51 PM:
-
# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
was (Author: dlmiles):
# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles commented on MANTRUN-177:
-
# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles edited comment on MANTRUN-177 at 1/2/13 9:52 PM:
-
'# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
'# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
was (Author: dlmiles):
'# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
'# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles edited comment on MANTRUN-177 at 1/2/13 9:53 PM:
-
'# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
'# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
{{
${env.MY_VARIABLE_ON_THIS_HOST}
}}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
was (Author: dlmiles):
'# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
'# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles edited comment on MANTRUN-177 at 1/2/13 9:53 PM:
-
bq.# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
bq.# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
bq.
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
was (Author: dlmiles):
'# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
'# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
{{
${env.MY_VARIABLE_ON_THIS_HOST}
}}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles edited comment on MANTRUN-177 at 1/2/13 9:54 PM:
-
{code}# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
{code}
{code:xml}
${env.MY_VARIABLE_ON_THIS_HOST}
{code}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
was (Author: dlmiles):
{code}# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
{code}
{code:xml}
${env.MY_VARIABLE_ON_THIS_HOST}
{code}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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] (MANTRUN-177) Ant properties not passed to maven 3.0.4
[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316523#comment-316523
]
Darryl L. Miles edited comment on MANTRUN-177 at 1/2/13 9:54 PM:
-
{code}# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
{code}
{code:xml}
${env.MY_VARIABLE_ON_THIS_HOST}
{code}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
was (Author: dlmiles):
bq.# Unix
MY_VARIABLE_ON_THIS_HOST=prd
export MY_VARIABLE_ON_THIS_HOST
bq.# Windows
set MY_VARIABLE_ON_THIS_HOST=prd
bq.
${env.MY_VARIABLE_ON_THIS_HOST}
You can use the 'maven-enforcer-plugin' [
https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html ] to fail
any Maven usage that does not setup the environment variable first. There is
but I'd use for
${filters.file} being a non-empty value, or better any one of the valid values
^(pc|dev|test|prd)$ info on this at
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
You can configure the environment variable in a place on each system that is
globally picked up by all logged in users /etc/profile on Unix or System
Properties on Windows.
Now you no longer need to tie your config to a 'hostname' which is an unrelated
information, you also do not need an 'ANT' dependency if this is the only use.
> Ant properties not passed to maven 3.0.4
>
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
>
>
> ${filters.file}
>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
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:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles edited comment on SCM-557 at 1/16/13 9:20 AM: -- The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm was (Author: dlmiles): The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > 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 : > [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 ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." 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 agr
[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:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles edited comment on SCM-557 at 1/16/13 9:20 AM: -- The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm was (Author: dlmiles): The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > 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 : > [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 ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." 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 > ac
[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:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles commented on SCM-557: - The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > 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 : > [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 ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." 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.DefaultLifec
[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:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles edited comment on SCM-557 at 1/16/13 9:22 AM: -- The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm was (Author: dlmiles): The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? ## What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm ## What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > 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 : > [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 ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." 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 sy
[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:comment-tabpanel&focusedCommentId=317431#comment-317431 ] Darryl L. Miles edited comment on SCM-557 at 1/16/13 9:22 AM: -- The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? ## What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm ## What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm was (Author: dlmiles): The message you see is coming from the server ? It is dangerous since you are not being explicit and the systems at one or both ends need to do some guess work. This guess can be wrong and therefore for a production system it is dangerous. A Maven module should not be ambiguously pushing... Related to SCM-705 ? # What maven is currently doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:real_asm # What maven should be doing: git push ssh://g...@git.codehaus.org/paranamer.git/ real_asm:refs/heads/real_asm > ERROR:gitosis.serve.main:Arguments to command look dangerous (apparently) > - > > Key: SCM-557 > URL: https://jira.codehaus.org/browse/SCM-557 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Paul Hammant > > 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 : > [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 ..." to unstage) > [DEBUG] # > [DEBUG] # modified: pom.xml > [DEBUG] # > [DEBUG] # Untracked files: > [DEBUG] # (use "git add ..." 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 thi
[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-tabpanel&focusedCommentId=317886#comment-317886
]
Darryl L. Miles commented on SCM-709:
-
@Tim
cd subdir/in/one/git/repo
git status --porcelain .
can be used to get SVN like behaviour where only the files changes below the
current directly are shown.
> 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-tabpanel&focusedCommentId=317886#comment-317886
]
Darryl L. Miles edited comment on SCM-709 at 1/23/13 4:13 PM:
--
@Tim
cd subdir/in/one/git/repo
git status --porcelain .
Note the use of the "." file name.
This can be used to get SVN like behaviour where only the files changes below
the current directly are shown.
was (Author: dlmiles):
@Tim
cd subdir/in/one/git/repo
git status --porcelain .
can be used to get SVN like behaviour where only the files changes below the
current directly are shown.
> 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] (MRELEASE-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319663#comment-319663 ] Darryl L. Miles commented on MRELEASE-780: -- I looked at things in mid Jan 2013 but am waiting for a bunch of my own bugs with provided patches to be applied to the appropriate tree before I waste any additional time looking and helping with resolving other bugs for the Maven project suite. I use the term 'waste' since some patches attached to Apache Maven related JIRA maybe as much as ~1 year old and I think there are at least 5 or more bugs with patches on this JIRA somewhere. If the maintainers don't have time to process them I don't have time to write patches. Plenty of other open source projects exist that are in need of spare development time and expertise. Sorry if this is not the answer you were hoping for maybe you have time to petition the appropriate maintainers in my behalf to try to make progress ion this basic open source project maintenance responsibility. > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: branch >Affects Versions: 2.3.2 >Reporter: W I > > If you create an release from the branch there should be no commits on the > tag-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] (MSHADE-144) Correct documentation examples ( not nested inside section)
Darryl L. Miles created MSHADE-144: -- Summary: Correct documentation examples ( not nested inside section) Key: MSHADE-144 URL: https://jira.codehaus.org/browse/MSHADE-144 Project: Maven 2.x Shade Plugin Issue Type: Task Affects Versions: 2.0 Reporter: Darryl L. Miles Priority: Trivial https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html In the last example at the bottom of the page The section should be inside the section surely ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-170) EAR plugin will emit invalid application.xml (without needing user override)
Darryl L. Miles created MEAR-170: Summary: EAR plugin will emit invalid application.xml (without needing user override) Key: MEAR-170 URL: https://jira.codehaus.org/browse/MEAR-170 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.8 Reporter: Darryl L. Miles The DTD/XSD for the application.xml indicates that it must contain both a and at least one element. Maven EAR plugin will emit by default, this bug ticket has no concerns there. But it is easy to configure it up with no valid . The plugin should have a new user-configurable attribute to enforce application.xml DTD/XSD rules. It should be in enforcing mode by default (so the plugin will cause a build error if the configuration causes an invalid application.xml to be emitted). When this situation is detected the user should be informed in the Maven error message that to override this check they can set -DenforceWellFormedApplicationXml=false The above information may not be correct for all EE versions of application.xml so for each EE version the rule(s) should be checked. But Maven by default should not be emitting invalid XML data, without the user overriding this check manually. There is also a use case to allow not emitting an application.xml at all when there is no configuration (no set). However again this should not be the default, if the user is using the EAR plugin they expect it to produce a well formed EAR artifact (and provide assistance towards that goal, by displaying appropriate error messages when they do something wrong). This means the default should be to always need to create an application.xml. Which then means they must configure the maven-ear-plugin correctly to achieve that goal (and not get a build failure). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-171) Full customization of FileNameMapping is needed (WTF is the "full" mode? This
Darryl L. Miles created MEAR-171:
Summary: Full customization of FileNameMapping is needed (WTF is
the "full" mode? This
Key: MEAR-171
URL: https://jira.codehaus.org/browse/MEAR-171
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Reporter: Darryl L. Miles
What is the logic with the seemingly non-standard conversion groupId by
replacing '.' with '-' in the "full" mode ? Surely this mode should have been
called "full-with-groupId-rewrite".
The purpose of this decision should have been documented in the code, someone
needs to do so or make this format obsolete.
Alternately the field should look at the maven-war-plugin and the ability to
support mapping like:
@{groupId}@.@{artifactId}@@{dashClassifier?}@-@{version}@.@{extension}@
Also the ${project.finalName} and ${project.name} would be useful (taken out of
the dependency's own POM, not the EAR project).
If this unusual replacement of groupId is required, then maybe
@{groupIdReplaceDots}@ can be provided.
The problem is that the names used are IMPORTANT to know and automate because
it maybe necessary to place them on the Class-Path in MANIFEST.MF files.
This non-standard choice needs to be explained because it really is
non-intuitive and there are no other mechanisms across the maven plugins to
manage and rewrite Class-Path values in accordance with this convention. There
is on the other hand clear ways to configure a project and decide on the output
file names on a project by project basis. This is what should be the default,
what the project itself decided it wanted to be called like
${project.finalName}.
The Maven documentation should include complete example of this "full"
behaviour along with explanation of why it is useful to the user.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-171) Full customization of FileNameMapping is needed (WTF is the "full" mode? This
[
https://jira.codehaus.org/browse/MEAR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324027#comment-324027
]
Darryl L. Miles commented on MEAR-171:
--
This is the code that currently implements "full"
https://maven.apache.org/plugins/maven-ear-plugin/xref/org/apache/maven/plugin/ear/output/FullFileNameMapping.html#35
> Full customization of FileNameMapping is needed (WTF is the "full" mode? This
> --
>
> Key: MEAR-171
> URL: https://jira.codehaus.org/browse/MEAR-171
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Darryl L. Miles
>
> What is the logic with the seemingly non-standard conversion groupId by
> replacing '.' with '-' in the "full" mode ? Surely this mode should have
> been called "full-with-groupId-rewrite".
> The purpose of this decision should have been documented in the code, someone
> needs to do so or make this format obsolete.
> Alternately the field should look at the maven-war-plugin and the ability to
> support mapping like:
> @{groupId}@.@{artifactId}@@{dashClassifier?}@-@{version}@.@{extension}@
> Also the ${project.finalName} and ${project.name} would be useful (taken out
> of the dependency's own POM, not the EAR project).
> If this unusual replacement of groupId is required, then maybe
> @{groupIdReplaceDots}@ can be provided.
> The problem is that the names used are IMPORTANT to know and automate because
> it maybe necessary to place them on the Class-Path in MANIFEST.MF files.
> This non-standard choice needs to be explained because it really is
> non-intuitive and there are no other mechanisms across the maven plugins to
> manage and rewrite Class-Path values in accordance with this convention.
> There is on the other hand clear ways to configure a project and decide on
> the output file names on a project by project basis. This is what should be
> the default, what the project itself decided it wanted to be called like
> ${project.finalName}.
> The Maven documentation should include complete example of this "full"
> behaviour along with explanation of why it is useful to the user.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
