[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Noland updated MENFORCER-146:
-
Attachment: RequireUpperBoundDepsVisitor.diff
I've attached a patch showing the behavior I find more useful. It uses the
preManagedVersion() of the DependencyNode, rather than the resolved version.
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
> Attachments: RequireUpperBoundDepsVisitor.diff
>
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-711) request for scm:info goal
[
https://jira.codehaus.org/browse/SCM-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317387#comment-317387
]
Karl Pietrzak commented on SCM-711:
---
Thank you, Olivier, but I feel like using the {{buildnumber-maven-plugin}} to
get the SVN rev or Git changeset is just a workaround around the fact that I
can't get it from {{scm}} plugin. I feel this is ironic, IMHO, because I can
branch using the {{scm}} plugin, but I can't get the revision.
Also {{buildnumber:create}} seems to be [only supported for
Subversion|http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html],
as compared to the plethora of SCMs that the Maven SCM plugin supports, most of
which already have some kind {{getInfo()}} method.
I'm not complaining: I'm offering to write a patch, if folks think this is
worthwhile.
Thanks!
> request for scm:info goal
> -
>
> Key: SCM-711
> URL: https://jira.codehaus.org/browse/SCM-711
> Project: Maven SCM
> Issue Type: Wish
> Components: maven-scm-api
>Reporter: Karl Pietrzak
>Priority: Minor
>
> h4. What
> I would like to request the addition of a {{scm:info}} goal.
> h4. Why
> I would like to use the properties of {{scm:info}} in the rest of my Maven
> build process, especially put SVN info properties into my manifest.
> h4. How
> Most (all?) of the providers have some kind of {{info}} method already, so it
> shouldn't be a big deal.
> I can submit a patch, if this sounds OK to folks.
--
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-711) request for scm:info goal
[
https://jira.codehaus.org/browse/SCM-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317386#comment-317386
]
Olivier Lamy commented on SCM-711:
--
try with http://mojo.codehaus.org/buildnumber-maven-plugin/
> request for scm:info goal
> -
>
> Key: SCM-711
> URL: https://jira.codehaus.org/browse/SCM-711
> Project: Maven SCM
> Issue Type: Wish
> Components: maven-scm-api
>Reporter: Karl Pietrzak
>Priority: Minor
>
> h4. What
> I would like to request the addition of a {{scm:info}} goal.
> h4. Why
> I would like to use the properties of {{scm:info}} in the rest of my Maven
> build process, especially put SVN info properties into my manifest.
> h4. How
> Most (all?) of the providers have some kind of {{info}} method already, so it
> shouldn't be a big deal.
> I can submit a patch, if this sounds OK to folks.
--
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-136) Shade dependency reduced pom uses timestamp in artifact names instead of -SNAPSHOT
[ https://jira.codehaus.org/browse/MSHADE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317385#comment-317385 ] Hung Huynh commented on MSHADE-136: --- A configurable option to turn this feature on/off would also be great > Shade dependency reduced pom uses timestamp in artifact names instead of > -SNAPSHOT > -- > > Key: MSHADE-136 > URL: https://jira.codehaus.org/browse/MSHADE-136 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Hung Huynh > > The major problem that we run into is that Maven would download that exact > timestamp artifact instead of using the latest. > Instead of this > > org.mycom > management-core > 1.1.0-20130115.201411-23 > compile > > should have been this > > org.mycom > management-core > 1.1.0-SNAPSHOT > compile > -- 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-136) Shade dependency reduced pom uses timestamp in artifact names instead of -SNAPSHOT
Hung Huynh created MSHADE-136: - Summary: Shade dependency reduced pom uses timestamp in artifact names instead of -SNAPSHOT Key: MSHADE-136 URL: https://jira.codehaus.org/browse/MSHADE-136 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Hung Huynh The major problem that we run into is that Maven would download that exact timestamp artifact instead of using the latest. Instead of this org.mycom management-core 1.1.0-20130115.201411-23 compile should have been this org.mycom management-core 1.1.0-SNAPSHOT compile -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
[
https://jira.codehaus.org/browse/MENFORCER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-146:
-
Description:
Consider the following dependency tree:
{noformat}
A
+- B
| \-X (1.1)
+- C
\-X (2.1)
{noformat}
I can use the requireUpperBoundDeps to find these types of issues (I want to
use D 2.1 rather than 1.1).
To fix the issue I use dependencyManagement to set the version of X to 2.1.
As I understand it, using dependencyManagement effectively changes the tree to
look like this:
{noformat}
A
+- B
| \-X (2.1) (really 1.1, but managed to 2.1)
+- C
\-X (2.1)
{noformat}
Now, if B is upgraded to depend on X 2.5, I will never know:
{noformat}
A
+- B
| \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
+- C
\-X (2.1)
{noformat}
was:
Consider the following dependency tree:
A
+- B
| \-X (1.1)
+- C
\-X (2.1)
I can use the requireUpperBoundDeps to find these types of issues (I want to
use D 2.1 rather than 1.1).
To fix the issue I use dependencyManagement to set the version of X to 2.1.
As I understand it, using dependencyManagement effectively changes the tree to
look like this:
A
+- B
| \-X (2.1) (really 1.1, but managed to 2.1)
+- C
\-X (2.1)
Now, if B is upgraded to depend on X 2.5, I will never know:
A
+- B
| \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
+- C
\-X (2.1)
> requireUpperBoundDeps inneffective when DependencyManagement is used
>
>
> Key: MENFORCER-146
> URL: https://jira.codehaus.org/browse/MENFORCER-146
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: Ben Noland
>
> Consider the following dependency tree:
> {noformat}
> A
> +- B
> | \-X (1.1)
> +- C
>\-X (2.1)
> {noformat}
> I can use the requireUpperBoundDeps to find these types of issues (I want to
> use D 2.1 rather than 1.1).
> To fix the issue I use dependencyManagement to set the version of X to 2.1.
> As I understand it, using dependencyManagement effectively changes the tree
> to look like this:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 1.1, but managed to 2.1)
> +- C
>\-X (2.1)
> {noformat}
> Now, if B is upgraded to depend on X 2.5, I will never know:
> {noformat}
> A
> +- B
> | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!)
> +- C
>\-X (2.1)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317380#comment-317380
]
Fred Cooke commented on MRELEASE-814:
-
OK, so we're on the same page completely, now, then :-)
> Property interpolation of developerConnection broken when inheritting from
> parent
> -
>
> Key: MRELEASE-814
> URL: https://jira.codehaus.org/browse/MRELEASE-814
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0, 2.3.2, 2.4
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Priority: Critical
> Attachments: demo.project.git.release.bug.tgz
>
>
> If {{developerConnection}} is setup like this in a parent and inherited:
> {code:xml}
> scm:git:git:${project.groupId}/${project.artifactId}.git
> {code}
> Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
> (and perhaps other operations)
> In the example project that I've included this is what it tries to do:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
> git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
> master:master
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project ShouldSeeThisOnceOnly: Unable to commit files
> [ERROR] W access for
> com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
> {noformat}
> I've used this same method with the property directly in the project POM with
> success. It seems that having it in the parent is the issue.
> Note, .ssh/config setup is required for a URL of this nature:
> {noformat}
> host git
> user git
> hostname localhost
> port 22
> identityfile ~/.ssh/id_rsa
> {noformat}
> Change these, and the deploy details to suit yourself.
> I sincerely hope that I'm doing something stupid and that this is not a bug
> as I desperately need to do some releases and waiting for a fix wouldn't be
> ideal, nor would hacking what should be inherited into each POM. Sadly, I
> doubt that I'm wrong this time, as I copy pasted the exact contents from my
> bogus parent into my pom, removed the parent ref, and it works as expected.
> This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-276) Read timed out during release:perform after updating to Maven 2.2
[
https://jira.codehaus.org/browse/WAGON-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated WAGON-276:
-
Description:
Artifact deployment fails with Maven 2.2:
{noformat}
[INFO] [DEBUG] Read timed out
[INFO] java.net.SocketTimeoutException: Read timed out
[INFO] at java.net.SocketInputStream.socketRead0(Native Method)
[INFO] at java.net.SocketInputStream.read(SocketInputStream.java:129)
[INFO] at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
[INFO] at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
[INFO] at
hidden.org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
[INFO] at
hidden.org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
[INFO] at
hidden.org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
[INFO] at
hidden.org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
[INFO] at
hidden.org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
[INFO] at
hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
[INFO] at
hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
[INFO] at
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:446)
[INFO] at
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:330)
[INFO] at
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280)
[INFO] at
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262)
[INFO] at
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172)
[INFO] at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
[INFO] at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173)
[INFO] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
[INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
[INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
[INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
[INFO] at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
[INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO] at java.lang.reflect.Method.invoke(Method.java:597)
[INFO] at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[INFO] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[INFO] at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[INFO] at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] [INFO]
[INFO] [ERROR] BUILD ERROR
[INFO] [INFO]
[INFO] [INFO] Error deploying artifact: Read timed out
[INFO]
[INFO] [INFO]
[INFO] [DEBUG] Trace
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifact: Read timed out
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
[INFO] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
[INFO] at
org.apache.maven.li
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317379#comment-317379
]
Robert Scholte commented on MRELEASE-814:
-
With a little less words that was my thought when writing "The only project
which could inherit is the executionProject, all modules should extend"
> Property interpolation of developerConnection broken when inheritting from
> parent
> -
>
> Key: MRELEASE-814
> URL: https://jira.codehaus.org/browse/MRELEASE-814
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0, 2.3.2, 2.4
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Priority: Critical
> Attachments: demo.project.git.release.bug.tgz
>
>
> If {{developerConnection}} is setup like this in a parent and inherited:
> {code:xml}
> scm:git:git:${project.groupId}/${project.artifactId}.git
> {code}
> Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
> (and perhaps other operations)
> In the example project that I've included this is what it tries to do:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
> git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
> master:master
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project ShouldSeeThisOnceOnly: Unable to commit files
> [ERROR] W access for
> com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
> {noformat}
> I've used this same method with the property directly in the project POM with
> success. It seems that having it in the parent is the issue.
> Note, .ssh/config setup is required for a URL of this nature:
> {noformat}
> host git
> user git
> hostname localhost
> port 22
> identityfile ~/.ssh/id_rsa
> {noformat}
> Change these, and the deploy details to suit yourself.
> I sincerely hope that I'm doing something stupid and that this is not a bug
> as I desperately need to do some releases and waiting for a fix wouldn't be
> ideal, nor would hacking what should be inherited into each POM. Sadly, I
> doubt that I'm wrong this time, as I copy pasted the exact contents from my
> bogus parent into my pom, removed the parent ref, and it works as expected.
> This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5363) Regression for SSLv3
[ https://jira.codehaus.org/browse/MNG-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5363: Priority: Critical (was: Major) > Regression for SSLv3 > > > Key: MNG-5363 > URL: https://jira.codehaus.org/browse/MNG-5363 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Errors >Affects Versions: 3.0.4 > Environment: Operation system independent, but tested on Macbook Pro > with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. >Reporter: James Kionka >Priority: Critical > > When attempting to access a Maven repository which uses SSLv3, you get the > following error, "javax.net.ssl.SSLException: Received fatal alert: > bad_record_mac". > Earlier versions of Maven used java.net.URLConnection which respects the > https.protocols system property. This allowed us to set it to SSLv3, which is > what our Maven repository uses. However, HttpClient ignores that property. In > other situations, we programmatically tell HttpClient to use SSLv3, which we > cannot do from our end. > You can find another person in the same situation here: > http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-742) Regression in 2.2.2 related to maven-gpg-plugin
[ https://jira.codehaus.org/browse/MRELEASE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317376#comment-317376 ] Gili commented on MRELEASE-742: --- Robert, I'll try what you suggested in a few days (unfortunately I'm tied up with critical work for the next 2 days). On a side-note, can you please give MNG-5363 a nudge? We need someone to update Component, Priority and possibly assign it to the right person. I don't have the necessary permissions. > Regression in 2.2.2 related to maven-gpg-plugin > --- > > Key: MRELEASE-742 > URL: https://jira.codehaus.org/browse/MRELEASE-742 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.2.2 > Environment: OS X 10.6, Maven 3.0.3, maven-gpg-plugin 1.4 >Reporter: Andres Rodriguez > > After updating to Release Plugin 2.2.2 gpg plugin fails with error: > "Cannot obtain passphrase in batch mode" > Which is thrown (see > http://maven.apache.org/plugins/maven-gpg-plugin/xref/org/apache/maven/plugin/gpg/AbstractGpgMojo.html) > when the passphrase has not been set and the use agent parameter is > false. The passphrase is set in my settings.xml and the useAgent has the > default false value. > Downgrading to 2.2.1 fixes the problem and the built artifacts are correctly > signed. > An example POM project can be found at: > http://code.google.com/p/derquinse-commons/source/browse/trunk/derquinse-pom/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-742) Regression in 2.2.2 related to maven-gpg-plugin
[
https://jira.codehaus.org/browse/MRELEASE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317375#comment-317375
]
Robert Scholte commented on MRELEASE-742:
-
Maven 3.0.4 fixes an issue with {{Profile}} merging in {{settings.xml}} which
was there since the first Maven3 release. What you could try: run the project
with Maven-3.0.4, and set the
[maven-release-plugin#mavenHome|http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#mavenHome]
property to Maven-3.0.3
> Regression in 2.2.2 related to maven-gpg-plugin
> ---
>
> Key: MRELEASE-742
> URL: https://jira.codehaus.org/browse/MRELEASE-742
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.2.2
> Environment: OS X 10.6, Maven 3.0.3, maven-gpg-plugin 1.4
>Reporter: Andres Rodriguez
>
> After updating to Release Plugin 2.2.2 gpg plugin fails with error:
> "Cannot obtain passphrase in batch mode"
> Which is thrown (see
> http://maven.apache.org/plugins/maven-gpg-plugin/xref/org/apache/maven/plugin/gpg/AbstractGpgMojo.html)
> when the passphrase has not been set and the use agent parameter is
> false. The passphrase is set in my settings.xml and the useAgent has the
> default false value.
> Downgrading to 2.2.1 fixes the problem and the built artifacts are correctly
> signed.
> An example POM project can be found at:
> http://code.google.com/p/derquinse-commons/source/browse/trunk/derquinse-pom/pom.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5363) Regression for SSLv3
[ https://jira.codehaus.org/browse/MNG-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317374#comment-317374 ] Gili commented on MNG-5363: --- Is the "component" on this bug report correct? Shouldn't this be fixed against Maven core or the release plugin? > Regression for SSLv3 > > > Key: MNG-5363 > URL: https://jira.codehaus.org/browse/MNG-5363 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Errors >Affects Versions: 3.0.4 > Environment: Operation system independent, but tested on Macbook Pro > with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. >Reporter: James Kionka > > When attempting to access a Maven repository which uses SSLv3, you get the > following error, "javax.net.ssl.SSLException: Received fatal alert: > bad_record_mac". > Earlier versions of Maven used java.net.URLConnection which respects the > https.protocols system property. This allowed us to set it to SSLv3, which is > what our Maven repository uses. However, HttpClient ignores that property. In > other situations, we programmatically tell HttpClient to use SSLv3, which we > cannot do from our end. > You can find another person in the same situation here: > http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-742) Regression in 2.2.2 related to maven-gpg-plugin
[ https://jira.codehaus.org/browse/MRELEASE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317373#comment-317373 ] Gili edited comment on MRELEASE-742 at 1/15/13 1:36 PM: Hi Robert, Maven 3.0.3, Ubuntu 12.04, 64-bit. Please note I cannot use Maven 3.0.4 because of this bug: http://jira.codehaus.org/browse/MNG-5363 was (Author: cowwoc): Hi Robert, Maven 3.0.3, Ubuntu 12.04, 64-bit. > Regression in 2.2.2 related to maven-gpg-plugin > --- > > Key: MRELEASE-742 > URL: https://jira.codehaus.org/browse/MRELEASE-742 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.2.2 > Environment: OS X 10.6, Maven 3.0.3, maven-gpg-plugin 1.4 >Reporter: Andres Rodriguez > > After updating to Release Plugin 2.2.2 gpg plugin fails with error: > "Cannot obtain passphrase in batch mode" > Which is thrown (see > http://maven.apache.org/plugins/maven-gpg-plugin/xref/org/apache/maven/plugin/gpg/AbstractGpgMojo.html) > when the passphrase has not been set and the use agent parameter is > false. The passphrase is set in my settings.xml and the useAgent has the > default false value. > Downgrading to 2.2.1 fixes the problem and the built artifacts are correctly > signed. > An example POM project can be found at: > http://code.google.com/p/derquinse-commons/source/browse/trunk/derquinse-pom/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-742) Regression in 2.2.2 related to maven-gpg-plugin
[ https://jira.codehaus.org/browse/MRELEASE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317373#comment-317373 ] Gili commented on MRELEASE-742: --- Hi Robert, Maven 3.0.3, Ubuntu 12.04, 64-bit. > Regression in 2.2.2 related to maven-gpg-plugin > --- > > Key: MRELEASE-742 > URL: https://jira.codehaus.org/browse/MRELEASE-742 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.2.2 > Environment: OS X 10.6, Maven 3.0.3, maven-gpg-plugin 1.4 >Reporter: Andres Rodriguez > > After updating to Release Plugin 2.2.2 gpg plugin fails with error: > "Cannot obtain passphrase in batch mode" > Which is thrown (see > http://maven.apache.org/plugins/maven-gpg-plugin/xref/org/apache/maven/plugin/gpg/AbstractGpgMojo.html) > when the passphrase has not been set and the use agent parameter is > false. The passphrase is set in my settings.xml and the useAgent has the > default false value. > Downgrading to 2.2.1 fixes the problem and the built artifacts are correctly > signed. > An example POM project can be found at: > http://code.google.com/p/derquinse-commons/source/browse/trunk/derquinse-pom/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-742) Regression in 2.2.2 related to maven-gpg-plugin
[ https://jira.codehaus.org/browse/MRELEASE-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317372#comment-317372 ] Robert Scholte commented on MRELEASE-742: - Gili, what's your environment? Especially which Maven version? > Regression in 2.2.2 related to maven-gpg-plugin > --- > > Key: MRELEASE-742 > URL: https://jira.codehaus.org/browse/MRELEASE-742 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.2.2 > Environment: OS X 10.6, Maven 3.0.3, maven-gpg-plugin 1.4 >Reporter: Andres Rodriguez > > After updating to Release Plugin 2.2.2 gpg plugin fails with error: > "Cannot obtain passphrase in batch mode" > Which is thrown (see > http://maven.apache.org/plugins/maven-gpg-plugin/xref/org/apache/maven/plugin/gpg/AbstractGpgMojo.html) > when the passphrase has not been set and the use agent parameter is > false. The passphrase is set in my settings.xml and the useAgent has the > default false value. > Downgrading to 2.2.1 fixes the problem and the built artifacts are correctly > signed. > An example POM project can be found at: > http://code.google.com/p/derquinse-commons/source/browse/trunk/derquinse-pom/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-230) Performance is really bad for large artifacts
[ https://jira.codehaus.org/browse/MDEP-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317366#comment-317366 ] Olivier Lamy commented on MDEP-230: --- please upgrade your version to 2.5.1 and have a look at http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html#useJvmChmod which is true per default. > Performance is really bad for large artifacts > - > > Key: MDEP-230 > URL: https://jira.codehaus.org/browse/MDEP-230 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: unpack >Affects Versions: 2.1 > Environment: linux >Reporter: Jason Chaffee > > I have a 300mb tar.gz file that I need to unpack for one of my builds. I > takes over 10 minutes to unpack with the unpack goal. If I do it on the > cmd-line it takes less than 1 minute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-146) requireUpperBoundDeps inneffective when DependencyManagement is used
Ben Noland created MENFORCER-146: Summary: requireUpperBoundDeps inneffective when DependencyManagement is used Key: MENFORCER-146 URL: https://jira.codehaus.org/browse/MENFORCER-146 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Reporter: Ben Noland Consider the following dependency tree: A +- B | \-X (1.1) +- C \-X (2.1) I can use the requireUpperBoundDeps to find these types of issues (I want to use D 2.1 rather than 1.1). To fix the issue I use dependencyManagement to set the version of X to 2.1. As I understand it, using dependencyManagement effectively changes the tree to look like this: A +- B | \-X (2.1) (really 1.1, but managed to 2.1) +- C \-X (2.1) Now, if B is upgraded to depend on X 2.5, I will never know: A +- B | \-X (2.1) (really 2.5, but managed to 2.1, I want to know about this!!) +- C \-X (2.1) -- 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-230) Performance is really bad for large artifacts
[ https://jira.codehaus.org/browse/MDEP-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317363#comment-317363 ] Ahmed El-Madhoun commented on MDEP-230: --- Is there anyway we can utilize the Java 7 features, add support for symlink discovery and creation? > Performance is really bad for large artifacts > - > > Key: MDEP-230 > URL: https://jira.codehaus.org/browse/MDEP-230 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: unpack >Affects Versions: 2.1 > Environment: linux >Reporter: Jason Chaffee > > I have a 300mb tar.gz file that I need to unpack for one of my builds. I > takes over 10 minutes to unpack with the unpack goal. If I do it on the > cmd-line it takes less than 1 minute. -- 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] (MCHANGES-286) Support for Jira custom fields in jira-report columnNames
[
https://jira.codehaus.org/browse/MCHANGES-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317360#comment-317360
]
Jeff Black commented on MCHANGES-286:
-
I second the idea, as it is important concept for the report to be delivered to
external clients that do not have access to our internal JIRA system.
> Support for Jira custom fields in jira-report columnNames
> -
>
> Key: MCHANGES-286
> URL: https://jira.codehaus.org/browse/MCHANGES-286
> Project: Maven 2.x Changes Plugin
> Issue Type: Wish
> Components: jira
>Affects Versions: 2.7.1
>Reporter: Peter Friberg
>
> A lot of important info is often described in Jira custom fields. In my case,
> the report will not fulfill the requirements because I can't output some
> important customfields in the report.
> I would be happy to see support for this. For example, be able specify:
> {code:xml}Key,Type,Priority,Summary,customfield_10023,
> customfield_10041{code}
> The descriptive name of the customfield should be returned back to the report.
> It would be a good start with the simple custom field types, such as text
> fields and single select.
--
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-711) request for scm:info goal
Karl Pietrzak created SCM-711:
-
Summary: request for scm:info goal
Key: SCM-711
URL: https://jira.codehaus.org/browse/SCM-711
Project: Maven SCM
Issue Type: Wish
Components: maven-scm-api
Reporter: Karl Pietrzak
Priority: Minor
h4. What
I would like to request the addition of a {{scm:info}} goal.
h4. Why
I would like to use the properties of {{scm:info}} in the rest of my Maven
build process, especially put SVN info properties into my manifest.
h4. How
Most (all?) of the providers have some kind of {{info}} method already, so it
shouldn't be a big deal.
I can submit a patch, if this sounds OK to folks.
--
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] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lennart Jorelid updated MSITE-669:
--
Attachment: msite_669_v2.patch
Patch fix - forgot to use the
--show-copies-as-adds in the former patch.
Please use the v2 patch instead; this patch version is verified to work.
Also - please supply some feedback, folks.
> site:stage creates incorrect structure when module paths contains sets of
> "../"
> ---
>
> Key: MSITE-669
> URL: https://jira.codehaus.org/browse/MSITE-669
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module, relative links, site:stage(-deploy)
>Affects Versions: 3.1, 3.2
>Reporter: Lennart Jorelid
>Assignee: Lukas Theussl
> Attachments: msite_669.patch, msite_669_v2.patch,
> nazgul_tools_project_dependencies.png, nazgul_tools_project_dependencies.png,
> nazgul_tools_reactor_structure.png, sample.zip
>
>
> Given the module definitions given below, the site:stage goal produces sets
> of maps relative to the staging directory - i.e. outside of the target
> directory.
> {code:xml}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {code}
> The staged site should be fully included within the staging directory. It
> would appear that relativization of links for site:stage should take special
> links into consideration.
--
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] (SUREFIRE-951) Better handling of file.encoding system property
[
https://jira.codehaus.org/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317337#comment-317337
]
Stephan Schroevers commented on SUREFIRE-951:
-
Thinking about it some more, I guess any unit test that relies on a _specific_
default encoding is faulty, so the case can be made that point (1) above
_should not be_ necessary. Would like to hear other people's thoughts on that.
> Better handling of file.encoding system property
>
>
> Key: SUREFIRE-951
> URL: https://jira.codehaus.org/browse/SUREFIRE-951
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.13
> Environment: Any environment in which the file encoding is distinct
> from ${project.build.sourceEncoding}.
>Reporter: Stephan Schroevers
> Attachments: file-encoding-example.tbz
>
>
> It appears that Surefire doesn't (correctly) set
> {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} prior to running the
> tests. As a result the JVM will derive {{file.encoding}} from the
> environment's file encoding. This affects the return value of
> {{java.nio.charset.Charset#defaultCharset()}}, which reads the
> {{file.encoding}} system property exactly once, and is invoked very early on.
> Concretely this means that the unit tests are unnecessarily platform
> dependent.
> Thus I have two requests:
> # Make {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} the default.
> That is, the following configuration setting should be implied:
> {noformat}
> -Dfile.encoding=${project.build.sourceEncoding}
> {noformat}
> # Extend the method
> {{org.apache.maven.plugin.surefire.SurefireProperties#verifyLegalSystemProperties(org.apache.maven.plugin.logging.Log)}}
> such that is warns about users attempting to set the {{file.encoding}}
> property through the {{systemPropertyVariables}} configuration setting. Like
> with {{java.library.path}}, this does _not_ work.
> I have [attached|^file-encoding-example.tbz] a sample project that
> demonstrates the issue (simply run {{`mvn test`}}). Please have a look at the
> comments I added to the POM. I have tested this sample project only on Linux,
> but a colleague has confirmed that an instance of this issue can also be
> recreated on Windows.
> TIA for looking into this!
--
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] (SUREFIRE-951) Better handling of file.encoding system property
Stephan Schroevers created SUREFIRE-951:
---
Summary: Better handling of file.encoding system property
Key: SUREFIRE-951
URL: https://jira.codehaus.org/browse/SUREFIRE-951
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin, process forking
Affects Versions: 2.13
Environment: Any environment in which the file encoding is distinct
from ${project.build.sourceEncoding}.
Reporter: Stephan Schroevers
Attachments: file-encoding-example.tbz
It appears that Surefire doesn't (correctly) set
{{-Dfile.encoding=$\{project.build.sourceEncoding\}}} prior to running the
tests. As a result the JVM will derive {{file.encoding}} from the environment's
file encoding. This affects the return value of
{{java.nio.charset.Charset#defaultCharset()}}, which reads the
{{file.encoding}} system property exactly once, and is invoked very early on.
Concretely this means that the unit tests are unnecessarily platform dependent.
Thus I have two requests:
# Make {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} the default. That
is, the following configuration setting should be implied:
{noformat}
-Dfile.encoding=${project.build.sourceEncoding}
{noformat}
# Extend the method
{{org.apache.maven.plugin.surefire.SurefireProperties#verifyLegalSystemProperties(org.apache.maven.plugin.logging.Log)}}
such that is warns about users attempting to set the {{file.encoding}}
property through the {{systemPropertyVariables}} configuration setting. Like
with {{java.library.path}}, this does _not_ work.
I have [attached|^file-encoding-example.tbz] a sample project that demonstrates
the issue (simply run {{`mvn test`}}). Please have a look at the comments I
added to the POM. I have tested this sample project only on Linux, but a
colleague has confirmed that an instance of this issue can also be recreated on
Windows.
TIA for looking into this!
--
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-165) Invalid version[6] during mvn ear:generate-application-xml
[ https://jira.codehaus.org/browse/MEAR-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317332#comment-317332 ] Stéphane Nicoll commented on MEAR-165: -- please attach a project that reproduces the issue. > Invalid version[6] during mvn ear:generate-application-xml > --- > > Key: MEAR-165 > URL: https://jira.codehaus.org/browse/MEAR-165 > Project: Maven 2.x Ear Plugin > Issue Type: Bug > Environment: Maven 2.2.1 > Java 6 > Windows XP 64bit >Reporter: Marcin Cinik > > mvn ear:generate-application-xml > INFO] Building GTRS :: EAR > [INFO]task-segment: [ear:generate-application-xml] > ... > [ERROR] BUILD ERROR > [INFO] > > *[INFO] Invalid version[6]* > > > org.apache.maven.plugins > maven-ear-plugin > 2.8 > > *6* > lib > > ... > And in the documentation you have: > "The version of the application.xml to generate. Valid values are 1.3, 1.4, 5 > and *6*. > Default value is: 1.3." -- 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
