[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] (MNG-4226) Better detection of JAVA_HOME on Apple Mac OS X
[
https://jira.codehaus.org/browse/MNG-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315031#comment-315031
]
Tamás Cservenák commented on MNG-4226:
--
You can circumvent current maven deployments (3.0.4 inclusive) without
modifying them, by adding following file in {{/etc/mavenrc}}:
{noformat}
#!/bin/bash
JAVA_HOME=`/usr/libexec/java_home -v 1.7`
{noformat}
Note: this will make Maven use same Java system wide!
> Better detection of JAVA_HOME on Apple Mac OS X
> ---
>
> Key: MNG-4226
> URL: https://jira.codehaus.org/browse/MNG-4226
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Reporter: Alin Dreghiciu
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4226-apache-maven.patch
>
>
> On mac JAVA_HOME is detected by using the following code:
> {code}
>if [ -z "$JAVA_VERSION" ] ; then
> JAVA_VERSION="CurrentJDK"
>else
> echo "Using Java version: $JAVA_VERSION"
>fi
>if [ -z "$JAVA_HOME" ] ; then
>
> JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home
>fi
> {code}
> But this does not work in collaboration with Using "Java preferences" to
> change the actual java version to use as "CurrentJDK" does not change once
> you update the "java applications" order.
> There is an alternative (at least on Leopard) for determining current java
> home that is based on Java Preferences by using an apple provided script. So,
> as a replacement fo rthe code above the following could be used.
> {code}
>if [ -z "$JAVA_HOME" ] ; then
> JAVA_HOME=`/usr/libexec/java_home | tail -1`
>fi
> {code}
> Could also be taht this is teh first attempt and if fails use the current way
> of determining home.
--
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-4226) Better detection of JAVA_HOME on Apple Mac OS X
[
https://jira.codehaus.org/browse/MNG-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315031#comment-315031
]
Tamás Cservenák edited comment on MNG-4226 at 12/5/12 2:28 AM:
---
You can circumvent current maven deployments (3.0.4 inclusive) without
modifying them, by adding following file in {{/etc/mavenrc}}:
{noformat}
JAVA_HOME=`/usr/libexec/java_home -v 1.7`
{noformat}
Note: this will make Maven use same Java system wide!
was (Author: cstamas):
You can circumvent current maven deployments (3.0.4 inclusive) without
modifying them, by adding following file in {{/etc/mavenrc}}:
{noformat}
#!/bin/bash
JAVA_HOME=`/usr/libexec/java_home -v 1.7`
{noformat}
Note: this will make Maven use same Java system wide!
> Better detection of JAVA_HOME on Apple Mac OS X
> ---
>
> Key: MNG-4226
> URL: https://jira.codehaus.org/browse/MNG-4226
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
>Reporter: Alin Dreghiciu
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4226-apache-maven.patch
>
>
> On mac JAVA_HOME is detected by using the following code:
> {code}
>if [ -z "$JAVA_VERSION" ] ; then
> JAVA_VERSION="CurrentJDK"
>else
> echo "Using Java version: $JAVA_VERSION"
>fi
>if [ -z "$JAVA_HOME" ] ; then
>
> JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home
>fi
> {code}
> But this does not work in collaboration with Using "Java preferences" to
> change the actual java version to use as "CurrentJDK" does not change once
> you update the "java applications" order.
> There is an alternative (at least on Leopard) for determining current java
> home that is based on Java Preferences by using an apple provided script. So,
> as a replacement fo rthe code above the following could be used.
> {code}
>if [ -z "$JAVA_HOME" ] ; then
> JAVA_HOME=`/usr/libexec/java_home | tail -1`
>fi
> {code}
> Could also be taht this is teh first attempt and if fails use the current way
> of determining home.
--
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-5402) Better build number for git
[
https://jira.codehaus.org/browse/MNG-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Hammar closed MNG-5402.
--
Resolution: Fixed
Fixed in
[f95ab2e7cdb488442ab923abe6ec856efc993dd3|http://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=f95ab2e7cdb488442ab923abe6ec856efc993dd3]
> Better build number for git
> ---
>
> Key: MNG-5402
> URL: https://jira.codehaus.org/browse/MNG-5402
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.1.0
> Environment: staged 3.1.0 on Mac OS 10.7.x, Apple JDK 1.6.0
>Reporter: Anders Hammar
>Assignee: Anders Hammar
>Priority: Minor
> Fix For: 3.1.1
>
>
> After the switch to git, executing "mvn -v" we get something like:
> {quote}
> Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl; 2012-12-04
> 05:03:32+0100)
> {quote}
> A better build number for git would be nice.
--
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-342) scm:tag should support flat project layout
[ https://jira.codehaus.org/browse/SCM-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315065#comment-315065 ] Hannes Kogler commented on SCM-342: --- same problem here. we prefer the flat project structure and I don't want to configure hundreds of jenkins config steps for just doing a checkin of hundreds projects from different base-folders... > scm:tag should support flat project layout > -- > > Key: SCM-342 > URL: https://jira.codehaus.org/browse/SCM-342 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Affects Versions: 1.0 > Environment: Windows XP, Eclipse 3.3 >Reporter: Duncan Doyle > Attachments: flatProjectTagPatch.txt > > > I have a Maven2 Flat Project Layout as described here: > http://maven.apache.org/guides/mini/guide-ide-eclipse.html > Basically my directory layout is as follows: > /MavenRoot/pom.xml (this is the SuperPom) > /Module1/pom.xml > /Module2/pom.xml > /Module3/pom.xml > Modules 1,2 and 3 are specified in the section of the SuperPom > (e.g() ../Module1). Each POM contains its own CVS connection > URL. > When I execute the scm:tag goal on the SuperPom in the MavenRoot project, > only the MavenRoot project gets tagged. The same behaviour can be seen with > the scm:update goal, which was fixed by providing a scm:update-subprojects > goal. > I would like to see this behaviour fixed in the SCM plugin, while Maven2 > advices a Flat Project Layout when working with Eclipse. At this moment I > can't use the tag goal at all (it should be executed automatically by > CruiseControl on a succesfull build). -- 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=315076#comment-315076 ] Logan McGrath commented on MRELEASE-746: Beanstalk doesn't provide the Git URLs in the expected format and you have to fiddle with them before they work with the Git SCM implementation. What I ended up using was the SSH URL format: scm:git:ssh://git@[account].beanstalkapp.com/[project].git I'm good to go because I found a workaround (and reported the problem to Beanstalk.) Sorry I didn't update the ticket :( > 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.
[jira] (MRELEASE-746) SCM URL being mangled
[
https://jira.codehaus.org/browse/MRELEASE-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-746:
Description:
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.java:75)
at
org.apache.maven.shared.release.phase.AbstractScmCommitPhase.execute(AbstractScmCommitPhase.java:79)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:206)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:142)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:104)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:302)
... 22 more
{noformat}
was:
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 ele
[jira] (MSCMPUB-6) when creating a directory in svn, if checkout fails, wait a few seconds and retry
Herve Boutemy created MSCMPUB-6: --- Summary: when creating a directory in svn, if checkout fails, wait a few seconds and retry Key: MSCMPUB-6 URL: https://jira.codehaus.org/browse/MSCMPUB-6 Project: maven-scm-publish-plugin Issue Type: Improvement Affects Versions: 1.0-beta-2 Reporter: Herve Boutemy Apache svn has some latency between directory creation and availability for checkout, but the plugin checks-out content immediately, causing a failure retrying immediately, it works like a charm this "wait a few seconds and retry" pattern could be automated in the plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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=315077#comment-315077
]
Robert Scholte commented on MRELEASE-808:
-
I've added a test in
[r1417615|http://svn.apache.org/viewvc?rev=1417615&view=rev] which already
succeeds without the patch.
Could you first verify if the problem is solved after applying the 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] (SCM-705) Git pushes tag ambigiously
[
https://jira.codehaus.org/browse/SCM-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MRELEASE-807 to SCM-705:
-
Complexity: Intermediate
Component/s: (was: Git)
(was: scm)
maven-scm-provider-git
Affects Version/s: (was: 2.3.2)
1.8.1
Key: SCM-705 (was: MRELEASE-807)
Project: Maven SCM (was: Maven 2.x Release Plugin)
> 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
>
>
> 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] (MWAR-128) war goal does not copy empty directories from webapp directory
[
https://jira.codehaus.org/browse/MWAR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315078#comment-315078
]
Muneer Syed commented on MWAR-128:
--
Here is solution or workaround for this
Create a dummy file empty.tmp in the directory which you want to include e.g.
src/main/webapp/myemptydir/empty.tmp
And use packagingExcludes that file, in the war the dummy file will be skipped
but empty directory will be present
maven-war-plugin
${maven.war.plugin.version}
**/empty.tmp
> war goal does not copy empty directories from webapp directory
> --
>
> Key: MWAR-128
> URL: https://jira.codehaus.org/browse/MWAR-128
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Ken Geis
>
> I have an empty directory src/main/webapp/WEB-INF/logs. I expect it to be
> created in target when the war goal tells me "Copy webapp webResources to
> ..." It does not get created.
--
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-735) Profile activation working unpredictably
[
https://jira.codehaus.org/browse/MRELEASE-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315080#comment-315080
]
Robert Scholte commented on MRELEASE-735:
-
Could you try the maven-release-plugin 2.4-SNAPSHOT? Profile resolution has
changed for M3, so I can imagine that this is fixed as well.
> Profile activation working unpredictably
>
>
> Key: MRELEASE-735
> URL: https://jira.codehaus.org/browse/MRELEASE-735
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.2.2
>Reporter: Thorsten Koch
> Attachments: parent.zip
>
>
> In an attempt to work around issue
> http://jira.codehaus.org/browse/MASSEMBLY-457 I tried to use the following
> profiles to set a property depending of the existens of a certain directory
> in my multimodule build:
> {code:xml}
>
>
> runAssembly
>
>
> src/main/sql
>
>
>
> false
>
>
>
> dontRunAssembly
>
>
> src/main/sql
>
>
>
> true
>
>
>
> {code}
> This is working well in normal builds. I can use the ${skipAssembly} property
> to switch on and of the assembly plugin depending of the directory existence
> in my modules.
> However, in the build run by the release:perform goal, this does not work. In
> this case always the second profile from the above is activated, regardless
> if the directory exists or not.
> But I found out (after a lot of tries), that it DOES work if the order of the
> profiles above is just changed. So when I write it like this
> {code:xml}
>
>
> dontRunAssembly
>
>
> src/main/sql
>
>
>
> true
>
>
>
> runAssembly
>
>
> src/main/sql
>
>
>
> false
>
>
>
> {code}
> THEN it's working even in release:perform builds. I have no idea what the
> triggering change is, but it seems worth creating an issue.
--
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-410) Allow specifying specific profiles to execute in the prepare mojo
[ https://jira.codehaus.org/browse/MRELEASE-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315081#comment-315081 ] Robert Scholte commented on MRELEASE-410: - I consider to close this as "won't fix", because the active profile resolution has changed with MRELEASE-571 for Maven3: the plugin will only pass the (de)activated profiles from the commandline. > Allow specifying specific profiles to execute in the prepare mojo > - > > Key: MRELEASE-410 > URL: https://jira.codehaus.org/browse/MRELEASE-410 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0-beta-8 >Reporter: Vincent Massol > > Right now the mojo calls project.getActiveProfiles() and adds them > automatically to the "arguments". So they come in addition to profiles passed > with "-Darguments=-Pprofile1,profile2,etc". > We would like to only execute the passed profiles. I propose to add a > "releaseProfiles" configuration element (as for release:perform, except that > releaseProfiles values don't seem to be taken into account for perform for > some reason but that's another problem). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-839) If no tests are found that would match a given JUnit category, mvn test should not fail in multi-module project
[ https://jira.codehaus.org/browse/SUREFIRE-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-839: Comment: was deleted (was: This issue is a general problem that has no easy solution. Setting -DfailIfNoTests=false is the only solution currently) > If no tests are found that would match a given JUnit category, mvn test > should not fail in multi-module project > --- > > Key: SUREFIRE-839 > URL: https://jira.codehaus.org/browse/SUREFIRE-839 > Project: Maven Surefire > Issue Type: Improvement > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.12 >Reporter: Martin Burger > > In a multi-module project, I configured Surefire to execute tests of a > selected JUnit category only. Unfortunately, not all modules contain tests in > that category, which makes mvn test fail: > Tests in error: > initializationError(org.junit.runner.manipulation.Filter): No tests found > matching *foo.junit.categories.SlowTests from org.junit.runner.Request$1@15a > If a module does not contain any test that would match the given category, > Surefire should continue instead. Note that specifying -DfailIfNoTests=false > does not help in that case. -- 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-839) If no tests are found that would match a given JUnit category, mvn test should not fail in multi-module project
[ https://jira.codehaus.org/browse/SUREFIRE-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-839. --- Resolution: Fixed Fix Version/s: 2.13 Assignee: Kristian Rosenvold Fixed with IT in d342273c30c0ec8aa5ba58603b1d9ceea5039278 > If no tests are found that would match a given JUnit category, mvn test > should not fail in multi-module project > --- > > Key: SUREFIRE-839 > URL: https://jira.codehaus.org/browse/SUREFIRE-839 > Project: Maven Surefire > Issue Type: Improvement > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.12 >Reporter: Martin Burger >Assignee: Kristian Rosenvold > Fix For: 2.13 > > > In a multi-module project, I configured Surefire to execute tests of a > selected JUnit category only. Unfortunately, not all modules contain tests in > that category, which makes mvn test fail: > Tests in error: > initializationError(org.junit.runner.manipulation.Filter): No tests found > matching *foo.junit.categories.SlowTests from org.junit.runner.Request$1@15a > If a module does not contain any test that would match the given category, > Surefire should continue instead. Note that specifying -DfailIfNoTests=false > does not help in that case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-138) Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe
[ https://jira.codehaus.org/browse/MCHECKSTYLE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315090#comment-315090 ] Ronald Chen commented on MCHECKSTYLE-138: - This plugin is not thread-safe. I ran into an issue where two threads were trying to access the same static unsynchronzied hash map. I am using version 2.6 and multiple threads stuck in: "pool-1-thread-1" prio=10 tid=0x7fd128342000 nid=0x3f7 runnable [0x7fd12c86c000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.get(HashMap.java:303) at com.puppycrawl.tools.checkstyle.api.Utils.getPattern(Utils.java:161) at com.puppycrawl.tools.checkstyle.api.Utils.getPattern(Utils.java:144) at com.puppycrawl.tools.checkstyle.filters.SuppressionCommentFilter.setOffCommentFormat(SuppressionCommentFilter.java:316) at com.puppycrawl.tools.checkstyle.filters.SuppressionCommentFilter.(SuppressionCommentFilter.java:303) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at com.puppycrawl.tools.checkstyle.PackageObjectFactory.createObject(PackageObjectFactory.java:114) at com.puppycrawl.tools.checkstyle.PackageObjectFactory.doMakeObject(PackageObjectFactory.java:92) at com.puppycrawl.tools.checkstyle.PackageObjectFactory.createModule(PackageObjectFactory.java:148) at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:152) at com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:207) at org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:174) at org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:380) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) My info: $ mvn -v Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) Maven home: /home/rchen/dev/tools/apache-maven-3.0.4 Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre Default locale: en_CA, platform encoding: UTF-8 OS name: "linux", version: "2.6.36-020636-generic", arch: "amd64", family: "unix" > Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe > --- > > Key: MCHECKSTYLE-138 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-138 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Improvement >Reporter: Kristian Rosenvold > > The checkstyle plugin can be marked as threadSafe if checkstyle itself can be > verified to be thread safe. > "Someone" should ask the checkstyle community if this is the case. -- 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-668) using groupId in url href should expand comonent dots . into proper path name
warren crossing created MSITE-668: - Summary: using groupId in url href should expand comonent dots . into proper path name Key: MSITE-668 URL: https://jira.codehaus.org/browse/MSITE-668 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: documentation Affects Versions: 2.3 Reporter: warren crossing Priority: Minor http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-relationships.html groupId A groupId groups a set of related artifacts. Group identifiers generally resemble a Java package name. For example, the groupId org.apache.maven is the base groupId for all artifacts produced by the Apache Maven project. Group identifiers are translated into paths in the Maven Repository; for example, the org.apache.maven groupId can be found in /maven2/org/apache/maven on repo1.maven.org. Please help me identify where this should be done and if so and I will patch 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] (MNG-5404) Wrong resolution of dependency scope by Maven 3
Dmitry Batrak created MNG-5404:
--
Summary: Wrong resolution of dependency scope by Maven 3
Key: MNG-5404
URL: https://jira.codehaus.org/browse/MNG-5404
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0.4
Reporter: Dmitry Batrak
Attachments: build.log
For the following POM:
{noformat}
4.0.0
test
A
1.0
org.apache.axis2
axis2-xmlbeans
1.5
provided
org.apache.axis2
axis2-codegen
1.5
org.apache.geronimo.specs
geronimo-stax-api_1.0_spec
{noformat}
running 'mvn dependency:resolve' using Maven 3.0.4 yields a wrong result.
Namely, geronimo-stax-api_1.0_spec dependency is reported as having the
resolved scope of 'compile'. With Maven 2.2.1 I get the 'provided' scope, as
expected.
Debug log is attached.
--
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-5247) be able to propagate the proxy from settings.xml to plugins
[ https://jira.codehaus.org/browse/MNG-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315092#comment-315092 ] Boni Gopalan commented on MNG-5247: --- Setting SystemVariable to true works just fine for most environments. The proxy setting under setttings.xml should go away. At least it should move under profiles so that switching proxy is painless. Don't you feel the pain when you move from your work environment to home and suddenly you need to go and edit settings.xml for URL connections to work? :(. This works fine. org.apache.maven.plugins maven-surefire-plugin 2.12.4 true > be able to propagate the proxy from settings.xml to plugins > --- > > Key: MNG-5247 > URL: https://jira.codehaus.org/browse/MNG-5247 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: Romain manni-Bucau > Attachments: MAVEN-PLUGINS-PROXY.diff > > > can be nice if plugins could get proxies defined in settings.xml. > for surefire a way to do it without modifying the plugin is to set proxy > information in user properties (otherwise it doesn't work in forked mode) -- 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-5247) be able to propagate the proxy from settings.xml to plugins
[ https://jira.codehaus.org/browse/MNG-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315093#comment-315093 ] Romain manni-Bucau commented on MNG-5247: - Hmm, not sure it can be done for all plugin (got the need for dockbook and ant plugins) Moreover i use a script to switch proxy in my conf file so the pain is just when it is not propagated in my builds > be able to propagate the proxy from settings.xml to plugins > --- > > Key: MNG-5247 > URL: https://jira.codehaus.org/browse/MNG-5247 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: Romain manni-Bucau > Attachments: MAVEN-PLUGINS-PROXY.diff > > > can be nice if plugins could get proxies defined in settings.xml. > for surefire a way to do it without modifying the plugin is to set proxy > information in user properties (otherwise it doesn't work in forked mode) -- 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-5247) be able to propagate the proxy from settings.xml to plugins
[ https://jira.codehaus.org/browse/MNG-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315094#comment-315094 ] Boni Gopalan commented on MNG-5247: --- since it is a JVM switch setting -Djava.net.useSystemProxie=true to MAVEN_OPTS should make it work for all plugins (and anything else from within the code). > be able to propagate the proxy from settings.xml to plugins > --- > > Key: MNG-5247 > URL: https://jira.codehaus.org/browse/MNG-5247 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: Romain manni-Bucau > Attachments: MAVEN-PLUGINS-PROXY.diff > > > can be nice if plugins could get proxies defined in settings.xml. > for surefire a way to do it without modifying the plugin is to set proxy > information in user properties (otherwise it doesn't work in forked mode) -- 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-5247) be able to propagate the proxy from settings.xml to plugins
[ https://jira.codehaus.org/browse/MNG-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315094#comment-315094 ] Boni Gopalan edited comment on MNG-5247 at 12/5/12 11:45 PM: - since it is a JVM switch setting -Djava.net.useSystemProxies=true to MAVEN_OPTS should make it work for all plugins (and anything else from within the code). OOPS : Looks like there are more complications. Will work only for classes using java.net.* for network access. was (Author: devasur): since it is a JVM switch setting -Djava.net.useSystemProxie=true to MAVEN_OPTS should make it work for all plugins (and anything else from within the code). > be able to propagate the proxy from settings.xml to plugins > --- > > Key: MNG-5247 > URL: https://jira.codehaus.org/browse/MNG-5247 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: Romain manni-Bucau > Attachments: MAVEN-PLUGINS-PROXY.diff > > > can be nice if plugins could get proxies defined in settings.xml. > for surefire a way to do it without modifying the plugin is to set proxy > information in user properties (otherwise it doesn't work in forked mode) -- 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-5247) be able to propagate the proxy from settings.xml to plugins
[ https://jira.codehaus.org/browse/MNG-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315094#comment-315094 ] Boni Gopalan edited comment on MNG-5247 at 12/6/12 12:10 AM: - since it is a JVM switch setting -Djava.net.useSystemProxies=true to MAVEN_OPTS should make it work for all plugins (and anything else from within the code). EDIT: adding -Djava.net.useSystemProxies=true appended to MAVEN_OPTS did not work. However clean install -Djava.net.useSystemProxies=true works well with proxy on or proxy off. Surprised. I am sure I am missing something fundamental about the way MAVEN_OPTS is interpreted. Is it to set only the -X parameters? was (Author: devasur): since it is a JVM switch setting -Djava.net.useSystemProxies=true to MAVEN_OPTS should make it work for all plugins (and anything else from within the code). OOPS : Looks like there are more complications. Will work only for classes using java.net.* for network access. > be able to propagate the proxy from settings.xml to plugins > --- > > Key: MNG-5247 > URL: https://jira.codehaus.org/browse/MNG-5247 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: Romain manni-Bucau > Attachments: MAVEN-PLUGINS-PROXY.diff > > > can be nice if plugins could get proxies defined in settings.xml. > for surefire a way to do it without modifying the plugin is to set proxy > information in user properties (otherwise it doesn't work in forked mode) -- 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-668) using groupId in url href should expand comonent dots . into proper path name
[ https://jira.codehaus.org/browse/MSITE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315098#comment-315098 ] Lukas Theussl commented on MSITE-668: - I don't understand the issue. Can you provide an example of the current behavior vs. what you think it should be? > using groupId in url href should expand comonent dots . into proper path name > - > > Key: MSITE-668 > URL: https://jira.codehaus.org/browse/MSITE-668 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: documentation >Affects Versions: 2.3 >Reporter: warren crossing >Priority: Minor > > http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-relationships.html > groupId > A groupId groups a set of related artifacts. Group identifiers generally > resemble a Java package name. For example, the groupId org.apache.maven is > the base groupId for all artifacts produced by the Apache Maven project. > Group identifiers are translated into paths in the Maven Repository; for > example, the org.apache.maven groupId can be found in > /maven2/org/apache/maven on repo1.maven.org. > Please help me identify where this should be done and if so and I will patch > 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
