[jira] (MRELEASE-798) Commit additional files with release plugin
[ https://jira.codehaus.org/browse/MRELEASE-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317537#comment-317537 ] Thorsten Hoeger commented on MRELEASE-798: -- Hi, is there any progress planned? > Commit additional files with release plugin > --- > > Key: MRELEASE-798 > URL: https://jira.codehaus.org/browse/MRELEASE-798 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare, scm >Affects Versions: 2.3.2 >Reporter: Thorsten Hoeger > > Hi, > is there any possibility to have the release-plugin commit additional files > which were > generated/modified in the preparationGoals. > Now only the pom.xml is commited. Using scm-plugin has some serious drawbacks > in this > situation. > If it is not possible at the moment, is there any chance to get this in the > future. Maybe > there could be a parameter additionalCommitFiles with a list of files to > commit along with > pom.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANTRUN-178) Ignore precedence of mvn command line over property defined in section
Arata created MANTRUN-178: - Summary: Ignore precedence of mvn command line over property defined in section Key: MANTRUN-178 URL: https://jira.codehaus.org/browse/MANTRUN-178 Project: Maven 2.x Antrun Plugin Issue Type: Bug Affects Versions: 1.7 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) Java version: 1.6.0_22, vendor: Sun Microsystems Inc. OS name: "windows xp" arch: "x86" Reporter: Arata Attachments: antrun.zip When (Maven) property is not defined in section in pom.xml and (System) property is given at mvn command line, then such property is picked up properly in Ant target. When (Maven) property is defined in section in pom.xml and (System) property is given with different value at mvn command line, such property value in Ant target is kept to one defined in the section, not one given at mvn command line; and this conflicts with how other Maven plugins treats such property value. The expectation is that it picks up the value given at the mvn command line. The antrun.zip attachment contains a sample Maven project. please try it run like: mvn -Dproptest_sysprop="defined" -Dproptest_Overwrite=true initialize It will demonstrate the issue like: [echo] *** mvn recognizes proptest_Overwrite property value as "true". *** ... [echo] *** Checking integrity over proptest_Overwrite property as case of overwriting hard-coded property value at mvn command line. *** [echo] [echo] Dump of proptest_Overwrite value by Ant's echoproperties tag: ... [echoproperties] proptest_Overwrite=false [echo] [echo] Dump of proptest_Overwrite value by Ant's echo tag: [echo] proptest_Overwrite = true [echo] [echo] proptest_Overwrite property value could keep integrity at Ant's equals condition tag: its value is recognized as "true". [INFO] [INFO] BUILD FAILURE [INFO] ... [ERROR] Target exception: java.lang.RuntimeException: proptest_Overwrite property value could not keep integrity in Ant's Project object: expected "true" but actually "false" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-821) Profiles enabled on the command line are not passed to the forked maven instance
[
https://jira.codehaus.org/browse/MRELEASE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317526#comment-317526
]
Robert Scholte commented on MRELEASE-821:
-
You said 2.2.1, or is this the maven-release-version?
Assuming that the profiles are listed in the {{settings.xml}}, you need to
upgrade Maven to 3.0.4, as mentioned
http://maven.apache.org/maven-release/maven-release-plugin/
> Profiles enabled on the command line are not passed to the forked maven
> instance
>
>
> Key: MRELEASE-821
> URL: https://jira.codehaus.org/browse/MRELEASE-821
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4
>Reporter: Steve Ash
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: FS-RELEASE-RELEASE-31.log
>
>
> I enable some profiles on the command line, which activate our companies
> repositories. I see in the maven instance that is first called they are
> active.
> {panel}
> build 17-Jan-2013 12:40:34[INFO]
>
> build 17-Jan-2013 12:40:34[INFO] Building fuzzy-project 1.2.1-SNAPSHOT
> build 17-Jan-2013 12:40:34[INFO]
>
> ...
> build 17-Jan-2013 12:40:34[DEBUG] === PROJECT BUILD PLAN
>
> build 17-Jan-2013 12:40:34[DEBUG] Project:
> com.argodata.fuzzy:fuzzy-project:1.2.1-SNAPSHOT
> build 17-Jan-2013 12:40:34[DEBUG] Dependencies (collect): []
> build 17-Jan-2013 12:40:34[DEBUG] Dependencies (resolve): []
> build 17-Jan-2013 12:40:34[DEBUG] Repositories (dependencies): [central
> (http://membuild01:8081/artifactory/libs-release, releases), snapshots
> (http://membuild01:8081/artifactory/libs-snapshot, releases+snapshots),
> com.argodata (http://serv107.argo.local/archiva/repository/com.argodata,
> releases+snapshots)]
> {panel}
> When the prepare method forks a new maven instance, the profiles are not
> enabled, causing our repos to not be used:
> {panel}
> build 17-Jan-2013 12:41:21[INFO] [INFO]
>
> build 17-Jan-2013 12:41:21[INFO] [INFO] Building fuzzy-project 1.2.1
> build 17-Jan-2013 12:41:21[INFO] [INFO]
>
> ...
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] === PROJECT BUILD PLAN
>
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Project:
> com.argodata.fuzzy:fuzzy-project:1.2.1
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (collect): []
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (resolve): []
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (dependencies):
> [central (http://repo1.maven.org/maven2, releases)]
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (plugins) :
> [central (http://repo1.maven.org/maven2, releases)]
> {panel}
> We were using 2.2.1 and not getting some of our profiles passed to the forked
> process, but we were getting the repos there...so I'm really confused. I
> upgraded to 2.4 to fix the problem seeing that MRELEASE-260 seemed like the
> culprit. When I upgraded however, it started failing sooner due to this
> problem.
> So I'm lost.
> I've attached the whole log if you're interested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-821) Profiles enabled on the command line are not passed to the forked maven instance
[
https://jira.codehaus.org/browse/MRELEASE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317517#comment-317517
]
Steve Ash commented on MRELEASE-821:
I'm using Maven 3.0.3
> Profiles enabled on the command line are not passed to the forked maven
> instance
>
>
> Key: MRELEASE-821
> URL: https://jira.codehaus.org/browse/MRELEASE-821
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4
>Reporter: Steve Ash
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: FS-RELEASE-RELEASE-31.log
>
>
> I enable some profiles on the command line, which activate our companies
> repositories. I see in the maven instance that is first called they are
> active.
> {panel}
> build 17-Jan-2013 12:40:34[INFO]
>
> build 17-Jan-2013 12:40:34[INFO] Building fuzzy-project 1.2.1-SNAPSHOT
> build 17-Jan-2013 12:40:34[INFO]
>
> ...
> build 17-Jan-2013 12:40:34[DEBUG] === PROJECT BUILD PLAN
>
> build 17-Jan-2013 12:40:34[DEBUG] Project:
> com.argodata.fuzzy:fuzzy-project:1.2.1-SNAPSHOT
> build 17-Jan-2013 12:40:34[DEBUG] Dependencies (collect): []
> build 17-Jan-2013 12:40:34[DEBUG] Dependencies (resolve): []
> build 17-Jan-2013 12:40:34[DEBUG] Repositories (dependencies): [central
> (http://membuild01:8081/artifactory/libs-release, releases), snapshots
> (http://membuild01:8081/artifactory/libs-snapshot, releases+snapshots),
> com.argodata (http://serv107.argo.local/archiva/repository/com.argodata,
> releases+snapshots)]
> {panel}
> When the prepare method forks a new maven instance, the profiles are not
> enabled, causing our repos to not be used:
> {panel}
> build 17-Jan-2013 12:41:21[INFO] [INFO]
>
> build 17-Jan-2013 12:41:21[INFO] [INFO] Building fuzzy-project 1.2.1
> build 17-Jan-2013 12:41:21[INFO] [INFO]
>
> ...
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] === PROJECT BUILD PLAN
>
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Project:
> com.argodata.fuzzy:fuzzy-project:1.2.1
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (collect): []
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (resolve): []
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (dependencies):
> [central (http://repo1.maven.org/maven2, releases)]
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (plugins) :
> [central (http://repo1.maven.org/maven2, releases)]
> {panel}
> We were using 2.2.1 and not getting some of our profiles passed to the forked
> process, but we were getting the repos there...so I'm really confused. I
> upgraded to 2.4 to fix the problem seeing that MRELEASE-260 seemed like the
> culprit. When I upgraded however, it started failing sooner due to this
> problem.
> So I'm lost.
> I've attached the whole log if you're interested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status regexps invalid
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317514#comment-317514
]
Robert Scholte commented on SCM-709:
Differences between --short and --porcelain:
{quote}
1. The users color.status configuration is not respected; color will always be
off.
2. The users status.relativePaths configuration is not respected; paths shown
will always be relative to the repository root.
{quote}
So this is actually saying that the working directory is ignored. And if the
working directory is not the repository root, you're having an issue.
> REGRESSION: git status regexps invalid
> --
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> The regular expressions have changed, but they are too wide, which might
> cause invalid matches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-167) Classes from different modules with the same artifactId are merged when skinnyWars set to TRUE
Anton Shaykin created MEAR-167: -- Summary: Classes from different modules with the same artifactId are merged when skinnyWars set to TRUE Key: MEAR-167 URL: https://jira.codehaus.org/browse/MEAR-167 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.8 Reporter: Anton Shaykin Attachments: example.zip When some modules, that are to be included in ear, have the same artifactId, classes from those modules get merged. Consider this project structure . |-root |-app |--business |---service |--ejb |---service In this example, there are 2 ejb modules main.root.business:service:jar and main.root.ejb:service:jar with artifactId 'service'. Project app has the following build configuration: org.apache.maven.plugins maven-ear-plugin 2.8 true main.root.ejb service service1.jar main.root.business service service2.jar When I run maven-ear-plugin:ear goal I get an ear with 2 ejb jars in it (service1.jar and service2.jar), but the second one contains classes from both modules. I did some code digging, and this is what I've found (EarMojo, line 684): workDirectory = new File( new File( generatedDescriptorLocation, "temp" ), module.getArtifact().getArtifactId() ); workDirectory.mkdirs(); So, basically, when skinnyWars set to TRUE, you create a temporary folder with the name based on artifactId. That's why the classes are merged in the second jar. As a solution, I'd suggest either randomize the directory name, or at least check for a directory existence and remove it recursively, if found. The example project is attached to this ticket. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status regexps invalid
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317511#comment-317511
]
Robert Scholte commented on SCM-709:
Now we seem to have to root cause. Still weird that only a few people seem to
have trouble with it. The next question would be: which of the 2 values is
wrong?
> REGRESSION: git status regexps invalid
> --
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> The regular expressions have changed, but they are too wide, which might
> cause invalid matches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-821) Profiles enabled on the command line are not passed to the forked maven instance
[
https://jira.codehaus.org/browse/MRELEASE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-821.
---
Resolution: Not A Bug
Assignee: Robert Scholte
MRELEASE-571 is the issue responsible for the fix, and it has this quote:
{quote}
Be aware that this fix will only work for Maven3, because only this version has
an API to get the original passed commandline arguments.
To get the same result with Maven2 requires a lot of calculations and even then
it is not sure if all profiles are gathered.
{quote}
It is not possible to fix this for Maven2.
> Profiles enabled on the command line are not passed to the forked maven
> instance
>
>
> Key: MRELEASE-821
> URL: https://jira.codehaus.org/browse/MRELEASE-821
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4
>Reporter: Steve Ash
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: FS-RELEASE-RELEASE-31.log
>
>
> I enable some profiles on the command line, which activate our companies
> repositories. I see in the maven instance that is first called they are
> active.
> {panel}
> build 17-Jan-2013 12:40:34[INFO]
>
> build 17-Jan-2013 12:40:34[INFO] Building fuzzy-project 1.2.1-SNAPSHOT
> build 17-Jan-2013 12:40:34[INFO]
>
> ...
> build 17-Jan-2013 12:40:34[DEBUG] === PROJECT BUILD PLAN
>
> build 17-Jan-2013 12:40:34[DEBUG] Project:
> com.argodata.fuzzy:fuzzy-project:1.2.1-SNAPSHOT
> build 17-Jan-2013 12:40:34[DEBUG] Dependencies (collect): []
> build 17-Jan-2013 12:40:34[DEBUG] Dependencies (resolve): []
> build 17-Jan-2013 12:40:34[DEBUG] Repositories (dependencies): [central
> (http://membuild01:8081/artifactory/libs-release, releases), snapshots
> (http://membuild01:8081/artifactory/libs-snapshot, releases+snapshots),
> com.argodata (http://serv107.argo.local/archiva/repository/com.argodata,
> releases+snapshots)]
> {panel}
> When the prepare method forks a new maven instance, the profiles are not
> enabled, causing our repos to not be used:
> {panel}
> build 17-Jan-2013 12:41:21[INFO] [INFO]
>
> build 17-Jan-2013 12:41:21[INFO] [INFO] Building fuzzy-project 1.2.1
> build 17-Jan-2013 12:41:21[INFO] [INFO]
>
> ...
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] === PROJECT BUILD PLAN
>
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Project:
> com.argodata.fuzzy:fuzzy-project:1.2.1
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (collect): []
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (resolve): []
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (dependencies):
> [central (http://repo1.maven.org/maven2, releases)]
> build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (plugins) :
> [central (http://repo1.maven.org/maven2, releases)]
> {panel}
> We were using 2.2.1 and not getting some of our profiles passed to the forked
> process, but we were getting the repos there...so I'm really confused. I
> upgraded to 2.4 to fix the problem seeing that MRELEASE-260 seemed like the
> culprit. When I upgraded however, it started failing sooner due to this
> problem.
> So I'm lost.
> I've attached the whole log if you're interested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-821) Profiles enabled on the command line are not passed to the forked maven instance
Steve Ash created MRELEASE-821:
--
Summary: Profiles enabled on the command line are not passed to
the forked maven instance
Key: MRELEASE-821
URL: https://jira.codehaus.org/browse/MRELEASE-821
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.4
Reporter: Steve Ash
Priority: Blocker
Attachments: FS-RELEASE-RELEASE-31.log
I enable some profiles on the command line, which activate our companies
repositories. I see in the maven instance that is first called they are
active.
{panel}
build 17-Jan-2013 12:40:34[INFO]
build 17-Jan-2013 12:40:34[INFO] Building fuzzy-project 1.2.1-SNAPSHOT
build 17-Jan-2013 12:40:34[INFO]
...
build 17-Jan-2013 12:40:34[DEBUG] === PROJECT BUILD PLAN
build 17-Jan-2013 12:40:34[DEBUG] Project:
com.argodata.fuzzy:fuzzy-project:1.2.1-SNAPSHOT
build 17-Jan-2013 12:40:34[DEBUG] Dependencies (collect): []
build 17-Jan-2013 12:40:34[DEBUG] Dependencies (resolve): []
build 17-Jan-2013 12:40:34[DEBUG] Repositories (dependencies): [central
(http://membuild01:8081/artifactory/libs-release, releases), snapshots
(http://membuild01:8081/artifactory/libs-snapshot, releases+snapshots),
com.argodata (http://serv107.argo.local/archiva/repository/com.argodata,
releases+snapshots)]
{panel}
When the prepare method forks a new maven instance, the profiles are not
enabled, causing our repos to not be used:
{panel}
build 17-Jan-2013 12:41:21[INFO] [INFO]
build 17-Jan-2013 12:41:21[INFO] [INFO] Building fuzzy-project 1.2.1
build 17-Jan-2013 12:41:21[INFO] [INFO]
...
build 17-Jan-2013 12:41:21[INFO] [DEBUG] === PROJECT BUILD PLAN
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Project:
com.argodata.fuzzy:fuzzy-project:1.2.1
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (collect): []
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Dependencies (resolve): []
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (dependencies):
[central (http://repo1.maven.org/maven2, releases)]
build 17-Jan-2013 12:41:21[INFO] [DEBUG] Repositories (plugins) :
[central (http://repo1.maven.org/maven2, releases)]
{panel}
We were using 2.2.1 and not getting some of our profiles passed to the forked
process, but we were getting the repos there...so I'm really confused. I
upgraded to 2.4 to fix the problem seeing that MRELEASE-260 seemed like the
culprit. When I upgraded however, it started failing sooner due to this
problem.
So I'm lost.
I've attached the whole log if you're interested.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-425) Generating archetype doubles } for namespace
Dan Taylor created ARCHETYPE-425: Summary: Generating archetype doubles } for namespace Key: ARCHETYPE-425 URL: https://jira.codehaus.org/browse/ARCHETYPE-425 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.2 Environment: Windows / Mac OS x / Linux maven 2: 3.0.4 JDK 1.6.0_35_64 Reporter: Dan Taylor Priority: Minor Attachments: CorrectFragment.xml, expectedOutput.xml, IncorrectFragment.xml When executing a maven archetype which is substituting a user defined value into a service namespace for use with CXF / Apache Spring, the archetype generator leaves two braces rather than the single brace to close the namespace. I have attached three files, one with the correct fragment which does not generate the expected output, one with the incorrect fragment which does generate the expected output and the expected output. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-324) Site cannot be deployed when part of release plugin, scp method used and server uses ECDSA
[ https://jira.codehaus.org/browse/WAGON-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317499#comment-317499 ] Rafal Figas commented on WAGON-324: --- Just in case, to add RSA entry into known_hosts use: ssh-keyscan -t rsa hostname >> known_hosts > Site cannot be deployed when part of release plugin, scp method used and > server uses ECDSA > -- > > Key: WAGON-324 > URL: https://jira.codehaus.org/browse/WAGON-324 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Gentoo Linux, Maven 2.2.1 >Reporter: Rafal Figas > > When running mvn release:perform release plugin runs site-deploy. > Configuration of distribution of site uses SCP protocol. So, when it comes to > deploy a site SSH connection is being made. However "The authenticity of host > [target_host] can't be established". What was strange I had no problems in > calling "ssh target_host". There was no problem with establishing > authenticity of host, neither with logging in using key. Due to this: > http://jira.codehaus.org/browse/MRELEASE-424 > it was also impossible to answer the question about adding this key to > ~/.ssh/known_hosts, so whole build just hang. > What I noticed my known_hosts file contained something like: > target_host ecdsa-sha2-nistp256 E2V[...] > When I've replaced this entry with: > target_host,10.0.0.2 ssh-rsa B3N[...] > everything started working. Does that mean Release plugin (or Wagon, or > JSCh?) cannot use ECDSA? -- 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] (MEAR-162) skinnyWars with wars without manifest Class-Path attribute
[ https://jira.codehaus.org/browse/MEAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317489#comment-317489 ] Guillaume Boucherie commented on MEAR-162: -- In fact I think that the MANIFEST.MF will never be update because the org.codehaus.plexus.archiver.jar.Manifest getters (getMainSection and getSection) return new instance of Section object, so changes made on this instance will never impact current Manifest instance. If it could help I create a patch (it include the one provided by Laszlo Varadi) that contains an update skinny war it test, that test the MANIFEST.MF generated classpath. > skinnyWars with wars without manifest Class-Path attribute > -- > > Key: MEAR-162 > URL: https://jira.codehaus.org/browse/MEAR-162 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Laszlo Varadi > Attachments: EarMojo.patch, MEAR-162.patch > > > The classpath attribute should be set after populating with values, otherwise > the classpath will be empty in the war manifest in case when the attribute is > a newly created attribute. See patch. -- 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] (MEAR-162) skinnyWars with wars without manifest Class-Path attribute
[ https://jira.codehaus.org/browse/MEAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boucherie updated MEAR-162: - Attachment: MEAR-162.patch > skinnyWars with wars without manifest Class-Path attribute > -- > > Key: MEAR-162 > URL: https://jira.codehaus.org/browse/MEAR-162 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Laszlo Varadi > Attachments: EarMojo.patch, MEAR-162.patch > > > The classpath attribute should be set after populating with values, otherwise > the classpath will be empty in the war manifest in case when the attribute is > a newly created attribute. See patch. -- 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] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
Michal Michalski created MEAR-166: - Summary: 'skinnyWar' doesn't work well with dependencies of type 'ejb' Key: MEAR-166 URL: https://jira.codehaus.org/browse/MEAR-166 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.8 Environment: many different environments I've verified this on Reporter: Michal Michalski It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's dependencies should go to EAR's lib. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status regexps invalid
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317481#comment-317481
]
Tim Kettler commented on SCM-709:
-
The problem is not with the regex but with the processing afterwards.
{{GitStatusConsumer}} tries to construct a new File object from the
{{workingDirectory}} and the extracted path from the regex and then checks for
existence.
Values for me are:
{{workingDirectory}} =
/home/tik/Develop/barchart-bugs/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-02
{{files.get( 0 )}} =
barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-02/pom.xml
Obviously, the paths overlap and hence the check fails and the file is
discarded.
> REGRESSION: git status regexps invalid
> --
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> The regular expressions have changed, but they are too wide, which might
> cause invalid matches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4565) Multiple profile activation conditions does not work
[ https://jira.codehaus.org/browse/MNG-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317477#comment-317477 ] Ronny Pscheidl commented on MNG-4565: - This extension should solve the problem when all activation conditions are met: https://github.com/johnjcool/and-activation-profile-selector > Multiple profile activation conditions does not work > > > Key: MNG-4565 > URL: https://jira.codehaus.org/browse/MNG-4565 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.2.1 > Environment: All platforms. >Reporter: Nicholas Allen >Assignee: Brian Fox > Fix For: Issues to be reviewed for 3.x > > > According to the documentation at > http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html > a profile is activated when all activation conditions are met (which makes > sense of course). But when I try to use this it does not work. It seems maven > does an OR instead of an AND (which is not rearly as useful and is the > opposite of what the documentation says at the previous link). > For example, if I have one profile that is activated like this: > > false > >linux > > > and another profile that is activated like this: > > false > >linux > > > release > true > > > Then I would expect the second profile to only be activated if the OS is > linux and the release property is defined. > When I run 'mvn help:active-profiles' however, maven shows that both profiles > are active even though the release property is not defined. -- 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] (MDEP-342) maven-dependency-plugin goal build-classpath is not written in correct order.
[ https://jira.codehaus.org/browse/MDEP-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed MDEP-342. -- Resolution: Cannot Reproduce Fix Version/s: (was: 2.3) Changing to "cannot reproduce". > maven-dependency-plugin goal build-classpath is not written in correct order. > - > > Key: MDEP-342 > URL: https://jira.codehaus.org/browse/MDEP-342 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: build-classpath >Affects Versions: 2.4 >Reporter: Anders Lindgren > Attachments: classpathorderproblem.zip > > > When running the goal build-classpath, the order of the dependencies in the > output is not the same as in the pom. > The dependency:tree is however producing output in correct order. > Also, when producing an executable jar using the maven-jar-plugin with > addClasspath set to true, the result is correct. -- 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] (MDEP-342) maven-dependency-plugin goal build-classpath is not written in correct order.
[ https://jira.codehaus.org/browse/MDEP-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reopened MDEP-342: > maven-dependency-plugin goal build-classpath is not written in correct order. > - > > Key: MDEP-342 > URL: https://jira.codehaus.org/browse/MDEP-342 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: build-classpath >Affects Versions: 2.4 >Reporter: Anders Lindgren > Fix For: 2.3 > > Attachments: classpathorderproblem.zip > > > When running the goal build-classpath, the order of the dependencies in the > output is not the same as in the pom. > The dependency:tree is however producing output in correct order. > Also, when producing an executable jar using the maven-jar-plugin with > addClasspath set to true, the result is correct. -- 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] (MDEP-342) maven-dependency-plugin goal build-classpath is not written in correct order.
[ https://jira.codehaus.org/browse/MDEP-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Lindgren closed MDEP-342. Resolution: Fixed Fix Version/s: 2.3 Problem with build-classpath has been resolved > maven-dependency-plugin goal build-classpath is not written in correct order. > - > > Key: MDEP-342 > URL: https://jira.codehaus.org/browse/MDEP-342 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: build-classpath >Affects Versions: 2.4 >Reporter: Anders Lindgren > Fix For: 2.3 > > Attachments: classpathorderproblem.zip > > > When running the goal build-classpath, the order of the dependencies in the > output is not the same as in the pom. > The dependency:tree is however producing output in correct order. > Also, when producing an executable jar using the maven-jar-plugin with > addClasspath set to true, the result is correct. -- 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] (MDEP-342) maven-dependency-plugin goal build-classpath is not written in correct order.
[ https://jira.codehaus.org/browse/MDEP-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317465#comment-317465 ] Anders Lindgren commented on MDEP-342: -- Hi, Yes, I agree, I just re-tested with 2.6 and it works fine. (Seems to have been fixed in 2.3) I will close this ticket. the "list" goal still produces the output in another order, but that might be fine. > maven-dependency-plugin goal build-classpath is not written in correct order. > - > > Key: MDEP-342 > URL: https://jira.codehaus.org/browse/MDEP-342 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: build-classpath >Affects Versions: 2.4 >Reporter: Anders Lindgren > Attachments: classpathorderproblem.zip > > > When running the goal build-classpath, the order of the dependencies in the > output is not the same as in the pom. > The dependency:tree is however producing output in correct order. > Also, when producing an executable jar using the maven-jar-plugin with > addClasspath set to true, the result is correct. -- 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] (MEAR-164) support for useJvmChmod in archiver and true per default
[ https://jira.codehaus.org/browse/MEAR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll updated MEAR-164: - Fix Version/s: (was: 2.9) 2.8.1 > support for useJvmChmod in archiver and true per default > > > Key: MEAR-164 > URL: https://jira.codehaus.org/browse/MEAR-164 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Reporter: Seth Rife >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.8.1 > > Attachments: EarMojoPatch.txt > > > Add support for useJvmChmod in archiver. -- 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] (MEAR-158) Elements library-directory and env-entry out of sequence in application.xml for JEE 6
[ https://jira.codehaus.org/browse/MEAR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317464#comment-317464 ] Markus Reiterer edited comment on MEAR-158 at 1/17/13 2:54 AM: --- . was (Author: mreiterer): same issue here. when is the planned release date for 2.8.1 ? > Elements library-directory and env-entry out of sequence in application.xml > for JEE 6 > - > > Key: MEAR-158 > URL: https://jira.codehaus.org/browse/MEAR-158 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Marty Phelan > Fix For: 2.8.1 > > Attachments: application.xml, pom.xml, pom.xml, pom.xml > > > When the pom.xml for an JEE 6 EAR project contains plugin configuration > entries for both defaultLibBundleDir and env-entries, the resulting elements > in application.xml are out-of-sequence per specification. The generated order > is env-entry - library-directory. This should be reversed. > Attached are two files: the sample pom.xml and resulting application.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-158) Elements library-directory and env-entry out of sequence in application.xml for JEE 6
[ https://jira.codehaus.org/browse/MEAR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317463#comment-317463 ] Markus Reiterer commented on MEAR-158: -- same issue here, when is the planned release date for 2.8.1 ? Can you provide a bugfix version for this defect ? > Elements library-directory and env-entry out of sequence in application.xml > for JEE 6 > - > > Key: MEAR-158 > URL: https://jira.codehaus.org/browse/MEAR-158 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Marty Phelan > Fix For: 2.8.1 > > Attachments: application.xml, pom.xml, pom.xml, pom.xml > > > When the pom.xml for an JEE 6 EAR project contains plugin configuration > entries for both defaultLibBundleDir and env-entries, the resulting elements > in application.xml are out-of-sequence per specification. The generated order > is env-entry - library-directory. This should be reversed. > Attached are two files: the sample pom.xml and resulting application.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-158) Elements library-directory and env-entry out of sequence in application.xml for JEE 6
[ https://jira.codehaus.org/browse/MEAR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317464#comment-317464 ] Markus Reiterer commented on MEAR-158: -- same issue here. when is the planned release date for 2.8.1 ? > Elements library-directory and env-entry out of sequence in application.xml > for JEE 6 > - > > Key: MEAR-158 > URL: https://jira.codehaus.org/browse/MEAR-158 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Marty Phelan > Fix For: 2.8.1 > > Attachments: application.xml, pom.xml, pom.xml, pom.xml > > > When the pom.xml for an JEE 6 EAR project contains plugin configuration > entries for both defaultLibBundleDir and env-entries, the resulting elements > in application.xml are out-of-sequence per specification. The generated order > is env-entry - library-directory. This should be reversed. > Attached are two files: the sample pom.xml and resulting application.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-342) maven-dependency-plugin goal build-classpath is not written in correct order.
[ https://jira.codehaus.org/browse/MDEP-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317462#comment-317462 ] Anders Hammar commented on MDEP-342: Either I can't reproduce, or it migth be me missing something. Using Maven 3.0.4 on Mac OS 10.8.2 with Apple JDK 1.6.0_37, I get (with attached test project): mvn org.apache.maven.plugins:maven-dependency-plugin:2.4:build-classpath /Users/anders/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar:/Users/anders/.m2/repository/args4j/args4j/2.0.16/args4j-2.0.16.jar:/Users/anders/.m2/repository/com/thoughtworks/xstream/xstream/1.2.2/xstream-1.2.2.jar:/Users/anders/.m2/repository/xpp3/xpp3_min/1.1.3.4.O/xpp3_min-1.1.3.4.O.jar The same result with v2.6 of the plugin as well. And this is also the order I see in the POM (including transitive deps). In the manifest of the jar I get: Class-Path: lib/commons-logging-1.1.1.jar lib/args4j-2.0.16.jar lib/xs tream-1.2.2.jar lib/xpp3_min-1.1.3.4.O.jar All seems fine!? > maven-dependency-plugin goal build-classpath is not written in correct order. > - > > Key: MDEP-342 > URL: https://jira.codehaus.org/browse/MDEP-342 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: build-classpath >Affects Versions: 2.4 >Reporter: Anders Lindgren > Attachments: classpathorderproblem.zip > > > When running the goal build-classpath, the order of the dependencies in the > output is not the same as in the pom. > The dependency:tree is however producing output in correct order. > Also, when producing an executable jar using the maven-jar-plugin with > addClasspath set to true, the result is correct. -- 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
