[jira] (MNGSITE-174) Broken links to properties of "Require OS Version" of Maven Enforcer Plugin
[ https://jira.codehaus.org/browse/MNGSITE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323251#comment-323251 ] Jan Völker commented on MNGSITE-174: Sure, sorry: http://maven.apache.org/enforcer/enforcer-rules/requireOS.html > Broken links to properties of "Require OS Version" of Maven Enforcer Plugin > --- > > Key: MNGSITE-174 > URL: https://jira.codehaus.org/browse/MNGSITE-174 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Win 7 x64, Firefox >Reporter: Jan Völker >Priority: Minor > > For example the following link in the "Require OS Version" section of the > Maven Enforcer Plugin's site is broken and some others are as well. > arch - the cpu architecture. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-832) When performing a release, username and password parameters are ignored.
Sebastien Pinel created MRELEASE-832: Summary: When performing a release, username and password parameters are ignored. Key: MRELEASE-832 URL: https://jira.codehaus.org/browse/MRELEASE-832 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.4.1 Reporter: Sebastien Pinel Priority: Critical When you perform a release, username and password parameters are ignored. "mvn release:perform -Dusername=username -Dpassword=password -DconnectionUrl=scm:svn:http://whateverrepository/tags/0.0.1/"; This command was working fine in 2.3.2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-832) When performing a release, username and password parameters are ignored.
[ https://jira.codehaus.org/browse/MRELEASE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323261#comment-323261 ] Sebastien Pinel commented on MRELEASE-832: -- It is linked to this improvement "MRELEASE-796" which removed the parameters from this goal. > When performing a release, username and password parameters are ignored. > > > Key: MRELEASE-832 > URL: https://jira.codehaus.org/browse/MRELEASE-832 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.4.1 >Reporter: Sebastien Pinel >Priority: Critical > > When you perform a release, username and password parameters are ignored. > "mvn release:perform -Dusername=username -Dpassword=password > -DconnectionUrl=scm:svn:http://whateverrepository/tags/0.0.1/"; > This command was working fine in 2.3.2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5460) Transitive dependency with variable scope
Continuus Auchan created MNG-5460:
-
Summary: Transitive dependency with variable scope
Key: MNG-5460
URL: https://jira.codehaus.org/browse/MNG-5460
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0
Environment: Windows xp
Reporter: Continuus Auchan
Attachments: myproject.zip
We have a bad transitivity resolution when using variable scopes in our project
hierarchy on maven 3.
The same test on maven 2 gives us a correct behavior.
I've got a pom parent project with 3 modules.
In the parent pom I define :
-a property "myscope" with value "compile"
-a profile "myprofile" with a property "myscope" with value "provided"
The moduleA depends on nothing
The moduleB depends on moduleA with scope equals to myscope
The moduleC depends on moduleB with scope equals provided
When I enter the command "mvn dependency:tree -P myprofile" I've got
{quote}
--- maven-dependency-plugin:2.1:tree (default-cli) @ modB ---
com.mycompany.app:modB:jar:1.0-SNAPSHOT
\- com.mycompany.app:modA:jar:1.0-SNAPSHOT:provided
{quote}
which is OK, but I also have
{quote}
--- maven-dependency-plugin:2.1:tree (default-cli) @ modC ---
com.mycompany.app:modC:jar:1.0-SNAPSHOT
\- com.mycompany.app:modB:jar:1.0-SNAPSHOT:compile
\- com.mycompany.app:modA:jar:1.0-SNAPSHOT:compile
{quote}
where i do not excpect modA to appear.
You 'll find in attachment the sample project.
Note that the command "mvn dependency:tree" has the correct hehavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-833) release:prepare allows SNAPSHOT Plugin Dependencies
Chris Kreussling created MRELEASE-833: - Summary: release:prepare allows SNAPSHOT Plugin Dependencies Key: MRELEASE-833 URL: https://jira.codehaus.org/browse/MRELEASE-833 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.4 Environment: Maven 2.2.1 Reporter: Chris Kreussling When a Plugin Dependency references a SNAPSHOT version, release:prepare doesn't flag it. This allows a POM with SNAPSHOT dependencies on Plugins to be released. Example: This uses the FindBugs Plugin as an example, because that's what tripped us up. release:prepare didn't catch this. I suspect the same problem will occur for any Plugin Dependency that relies on a SNAPSHOT. org.codehaus.mojo findbugs-maven-plugin org.example my-findbugs-filters 0.1-SNAPSHOT include.xml exclude.xml check Circumvention: Duplicating the Plugin Dependency as an explicit dependency in the POM forces release:prepare to catch the problem. org.example my-findbugs-filters 0.1-SNAPSHOT provided -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-833) release:prepare allows SNAPSHOT Plugin Dependencies
[ https://jira.codehaus.org/browse/MRELEASE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-833. --- Resolution: Duplicate Assignee: Robert Scholte > release:prepare allows SNAPSHOT Plugin Dependencies > --- > > Key: MRELEASE-833 > URL: https://jira.codehaus.org/browse/MRELEASE-833 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.4 > Environment: Maven 2.2.1 >Reporter: Chris Kreussling >Assignee: Robert Scholte > > When a Plugin Dependency references a SNAPSHOT version, release:prepare > doesn't flag it. This allows a POM with SNAPSHOT dependencies on Plugins to > be released. > Example: This uses the FindBugs Plugin as an example, because that's what > tripped us up. release:prepare didn't catch this. I suspect the same problem > will occur for any Plugin Dependency that relies on a SNAPSHOT. > > org.codehaus.mojo > findbugs-maven-plugin > > > org.example > my-findbugs-filters > 0.1-SNAPSHOT > > > > include.xml > exclude.xml > > > > > check > > > > > Circumvention: Duplicating the Plugin Dependency as an explicit dependency in > the POM forces release:prepare to catch the problem. > > org.example > my-findbugs-filters > 0.1-SNAPSHOT > provided > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-833) release:prepare allows SNAPSHOT Plugin Dependencies
[
https://jira.codehaus.org/browse/MRELEASE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-833:
Description:
When a Plugin Dependency references a SNAPSHOT version, release:prepare doesn't
flag it. This allows a POM with SNAPSHOT dependencies on Plugins to be released.
Example: This uses the FindBugs Plugin as an example, because that's what
tripped us up. release:prepare didn't catch this. I suspect the same problem
will occur for any Plugin Dependency that relies on a SNAPSHOT.
{code:xml}
org.codehaus.mojo
findbugs-maven-plugin
org.example
my-findbugs-filters
0.1-SNAPSHOT
include.xml
exclude.xml
check
{code}
Circumvention: Duplicating the Plugin Dependency as an explicit dependency in
the POM forces release:prepare to catch the problem.
{code:xml}
org.example
my-findbugs-filters
0.1-SNAPSHOT
provided
{code}
was:
When a Plugin Dependency references a SNAPSHOT version, release:prepare doesn't
flag it. This allows a POM with SNAPSHOT dependencies on Plugins to be released.
Example: This uses the FindBugs Plugin as an example, because that's what
tripped us up. release:prepare didn't catch this. I suspect the same problem
will occur for any Plugin Dependency that relies on a SNAPSHOT.
org.codehaus.mojo
findbugs-maven-plugin
org.example
my-findbugs-filters
0.1-SNAPSHOT
include.xml
exclude.xml
check
Circumvention: Duplicating the Plugin Dependency as an explicit dependency in
the POM forces release:prepare to catch the problem.
org.example
my-findbugs-filters
0.1-SNAPSHOT
provided
> release:prepare allows SNAPSHOT Plugin Dependencies
> ---
>
> Key: MRELEASE-833
> URL: https://jira.codehaus.org/browse/MRELEASE-833
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.4
> Environment: Maven 2.2.1
>Reporter: Chris Kreussling
>Assignee: Robert Scholte
>
> When a Plugin Dependency references a SNAPSHOT version, release:prepare
> doesn't flag it. This allows a POM with SNAPSHOT dependencies on Plugins to
> be released.
> Example: This uses the FindBugs Plugin as an example, because that's what
> tripped us up. release:prepare didn't catch this. I suspect the same problem
> will occur for any Plugin Dependency that relies on a SNAPSHOT.
> {code:xml}
>
> org.codehaus.mojo
> findbugs-maven-plugin
>
>
> org.example
> my-findbugs-filters
> 0.1-SNAPSHOT
>
>
>
> include.xml
> exclude.xml
>
>
>
>
> check
>
>
>
>
> {code}
> Circumvention: Duplicating the Plugin Dependency as an explicit dependency in
> the POM forces release:prepare to catch the problem.
> {code:xml}
>
> org.example
> my-findbugs-filters
> 0.1-SNAPSHOT
> provided
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-972) Bizarre NoClassDefFoundError in failsafe
[
https://jira.codehaus.org/browse/SUREFIRE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-972.
---
Resolution: Fixed
Fix Version/s: 2.14.1
Fixed with IT in 01a3d7f6518faba42071e0954206c95055f94b19, thanks for producing
the test case!
> Bizarre NoClassDefFoundError in failsafe
>
>
> Key: SUREFIRE-972
> URL: https://jira.codehaus.org/browse/SUREFIRE-972
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Benson Margulies
>Assignee: Kristian Rosenvold
> Fix For: 2.14.1
>
>
> I'm tentatively stumped here and looking for debugging advice.
> {noformat}
> Running com.basistech.jug.upload.SolrMimicIT
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.112 sec <<<
> FAILURE!
> com.basistech.jug.upload.SolrMimicIT Time elapsed: 0.112 sec <<< ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class
> com.basistech.jug.upload.SolrMimicIT
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:169)
> at
> org.apache.maven.surefire.report.SmartStackTraceParser.getClass(SmartStackTraceParser.java:62)
> at
> org.apache.maven.surefire.report.SmartStackTraceParser.(SmartStackTraceParser.java:52)
> at
> org.apache.maven.surefire.common.junit4.JUnit4StackTraceWriter.smartTrimmedStackTrace(JUnit4StackTraceWriter.java:72)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:329)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:313)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:259)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.testError(ForkingRunListener.java:132)
> at
> org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:111)
> at
> org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:139)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:61)
> at
> org.junit.runner.notification.RunNotifier.fireTestFailures(RunNotifier.java:134)
> at
> org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:128)
> at
> org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:23)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:315)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> Results :
> Tests in error:
> JUnit4Provider.invoke:124->executeTestSet:153->execute:264 û
> NoClassDefFound C...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-241) Need a tagByProject that works like commitByProject
[
https://jira.codehaus.org/browse/MRELEASE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-241:
Description:
We have kind of an odd project layout because some of our developers only use
Eclipse for CVS, which doesn't handle shared poms that are not part of an
actual project very well. As a result, we have a project structure that looks
something like this:
{noformat}
|-- a
| `-- z
| |-- pom.xml
| `-- src
| `-- main
| `-- java
| `-- Test.java
`-- poms
|-- a
| `-- pom.xml
`-- pom.xml
{noformat}
Where {{poms/pom.xml}} is the top-level shared pom, {{poms/a/pom.xml}} is its
child, and {{a/z/pom.xml}} is a child of {{poms/a/pom.xml}}.
We have never got the release:prepare goal to work successfully on this
project. I discovered the commitByProject configuration property, which got us
a lot further when I set it to true. However, now there is a problem with the
CVS tag that it creates, because it runs "cvs tag" in the working directory,
and only once, instead of once for each project. We need that tagging to work
the same as the committing, where it executes the tag command once for each
pom. I'm attaching a sample project that demonstrates the problem when you run
"mvn release:prepare" on it.
was:
We have kind of an odd project layout because some of our developers only use
Eclipse for CVS, which doesn't handle shared poms that are not part of an
actual project very well. As a result, we have a project structure that looks
something like this:
|-- a
| `-- z
| |-- pom.xml
| `-- src
| `-- main
| `-- java
| `-- Test.java
`-- poms
|-- a
| `-- pom.xml
`-- pom.xml
Where poms/pom.xml is the top-level shared pom, poms/a/pom.xml is its child,
and a/z/pom.xml is a child of poms/a/pom.xml.
We have never got the release:prepare goal to work successfully on this
project. I discovered the commitByProject configuration property, which got us
a lot further when I set it to true. However, now there is a problem with the
CVS tag that it creates, because it runs "cvs tag" in the working directory,
and only once, instead of once for each project. We need that tagging to work
the same as the committing, where it executes the tag command once for each
pom. I'm attaching a sample project that demonstrates the problem when you run
"mvn release:prepare" on it.
> Need a tagByProject that works like commitByProject
> ---
>
> Key: MRELEASE-241
> URL: https://jira.codehaus.org/browse/MRELEASE-241
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-6
>Reporter: Tim McCune
> Fix For: Backlog
>
> Attachments: AbstractReleasePhase.java,
> maven-release-2.0-beta-7-cfs.patch, maven-release-2.0-beta-7-cfs.zip,
> releaseExample.tar.gz
>
>
> We have kind of an odd project layout because some of our developers only use
> Eclipse for CVS, which doesn't handle shared poms that are not part of an
> actual project very well. As a result, we have a project structure that
> looks something like this:
> {noformat}
> |-- a
> | `-- z
> | |-- pom.xml
> | `-- src
> | `-- main
> | `-- java
> | `-- Test.java
> `-- poms
> |-- a
> | `-- pom.xml
> `-- pom.xml
> {noformat}
> Where {{poms/pom.xml}} is the top-level shared pom, {{poms/a/pom.xml}} is its
> child, and {{a/z/pom.xml}} is a child of {{poms/a/pom.xml}}.
> We have never got the release:prepare goal to work successfully on this
> project. I discovered the commitByProject configuration property, which got
> us a lot further when I set it to true. However, now there is a problem with
> the CVS tag that it creates, because it runs "cvs tag" in the working
> directory, and only once, instead of once for each project. We need that
> tagging to work the same as the committing, where it executes the tag command
> once for each pom. I'm attaching a sample project that demonstrates the
> problem when you run "mvn release:prepare" on it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-241) Need a tagByProject that works like commitByProject
[
https://jira.codehaus.org/browse/MRELEASE-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323278#comment-323278
]
Robert Scholte commented on MRELEASE-241:
-
Apart from the fact that some SCM-systems don't support tagging of a specific
folder, in a hierarchical structure a tagByProject would tag too much (don't
think it is possible to exclude the module-folders). In a (oldfashion) flat
structure I can imagine the wish. A few weeks ago Stephen Connolly started a
thread about what he called "local aggregator".
His proposal starts with listing release-roots, a next step would be to
actually do a multi project release in one go.
Read http://maven.markmail.org/thread/ntwc537akvsjsegq to get an impression of
stategies, concerns and complexity.
> Need a tagByProject that works like commitByProject
> ---
>
> Key: MRELEASE-241
> URL: https://jira.codehaus.org/browse/MRELEASE-241
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-6
>Reporter: Tim McCune
> Fix For: Backlog
>
> Attachments: AbstractReleasePhase.java,
> maven-release-2.0-beta-7-cfs.patch, maven-release-2.0-beta-7-cfs.zip,
> releaseExample.tar.gz
>
>
> We have kind of an odd project layout because some of our developers only use
> Eclipse for CVS, which doesn't handle shared poms that are not part of an
> actual project very well. As a result, we have a project structure that
> looks something like this:
> {noformat}
> |-- a
> | `-- z
> | |-- pom.xml
> | `-- src
> | `-- main
> | `-- java
> | `-- Test.java
> `-- poms
> |-- a
> | `-- pom.xml
> `-- pom.xml
> {noformat}
> Where {{poms/pom.xml}} is the top-level shared pom, {{poms/a/pom.xml}} is its
> child, and {{a/z/pom.xml}} is a child of {{poms/a/pom.xml}}.
> We have never got the release:prepare goal to work successfully on this
> project. I discovered the commitByProject configuration property, which got
> us a lot further when I set it to true. However, now there is a problem with
> the CVS tag that it creates, because it runs "cvs tag" in the working
> directory, and only once, instead of once for each project. We need that
> tagging to work the same as the committing, where it executes the tag command
> once for each pom. I'm attaching a sample project that demonstrates the
> problem when you run "mvn release:prepare" on it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-538) mvn reactor:make-scm-changes fails for git provider with local git index
[
https://jira.codehaus.org/browse/SCM-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-538:
---
Description:
I have the following scm connection setup
{code:xml}
scm:git:file:..
scm:git:file:..
scm:git:file:..
{code}
Regular {{mvn scm:*}} commands work fine.
The maven reactor plugin seems to have a problem when I issue the following
command:
{{mvn -X reactor:make-scm-changes}}
It complains about invalid scm url. The stack trace seems to point to the
scm-provider.
{noformat}
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't configure SCM
repository: The scm url is invalid.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Couldn't configure
SCM repository: The scm url is invalid.
at
org.apache.maven.plugin.reactor.MakeScmChanges.execute(MakeScmChanges.java:88)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.scm.repository.ScmRepositoryException: The scm url
is invalid.
at
org.apache.maven.scm.provider.git.AbstractGitScmProvider.makeProviderScmRepository(AbstractGitScmProvider.java:93)
at
org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:192)
at
org.apache.maven.plugin.reactor.MakeScmChanges.execute(MakeScmChanges.java:83)
... 19 more
{noformat}
was:
I have the following scm connection setup
scm:git:file:..
scm:git:file:..
scm:git:file:..
Regular mvn scm:* commands work fine.
The maven reactor plugin seems to have a problem when I issue the following
command:
mvn -X reactor:make-scm-changes
It complains about invalid scm url. The stack trace seems to point to the
scm-provider.
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't configure SCM
repository: The scm url is invalid.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
[jira] (SCM-449) SvnUpdateCommand is updating all the working copy instead of only the fileSet passed in argument
[
https://jira.codehaus.org/browse/SCM-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-449:
---
Description:
{{scmManager.update()}} is updating all the files instead of the files given in
parameter:
{code}
lScmFile = new ScmFileSet(basedir, myFile);
lScmResult = scmManager.update(scmRepository, lScmFile);
{code}
Due to the {{SvnUpdateCommand.java}} which is updating all the working copy,
not only the {{FileSet}} given in argument. Here an extract of the line
{{executeUpdateCommand()}}:
{code}
Commandline cl = createCommandLine( (SvnScmProviderRepository) repo,
fileSet.getBasedir(), version );
{code}
Should not we use {{fileSet}} instead of {{fileSet.getBaseDir()}} ?
The {{SvnCheckInCommand()}} is using for instance the {{fileSet}} only
{code}
Commandline cl = createCommandLine( (SvnScmProviderRepository) repo,
fileSet, messageFile );
{code}
was:
scmManager.update() is updating all the files instead of the files given in
parameter:
lScmFile = new ScmFileSet(basedir, myFile);
lScmResult = scmManager.update(scmRepository, lScmFile);
Due to the SvnUpdateCommand.java which is updating all the working copy, not
only the FileSet given in argument. Here an extract of the line
executeUpdateCommand():
Commandline cl = createCommandLine( (SvnScmProviderRepository) repo,
fileSet.getBasedir(), version );
Should not we use fileSet instead of fileSet.getBaseDir() ?
The SvnCheckInCommand() is using for instance the fileSet only
Commandline cl = createCommandLine( (SvnScmProviderRepository) repo,
fileSet, messageFile );
> SvnUpdateCommand is updating all the working copy instead of only the fileSet
> passed in argument
>
>
> Key: SCM-449
> URL: https://jira.codehaus.org/browse/SCM-449
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.1
> Environment: maven 2.0.9
> Java 6
>Reporter: Jean-Paul GUIGUI
>
> {{scmManager.update()}} is updating all the files instead of the files given
> in parameter:
> {code}
> lScmFile = new ScmFileSet(basedir, myFile);
> lScmResult = scmManager.update(scmRepository, lScmFile);
> {code}
> Due to the {{SvnUpdateCommand.java}} which is updating all the working copy,
> not only the {{FileSet}} given in argument. Here an extract of the line
> {{executeUpdateCommand()}}:
> {code}
> Commandline cl = createCommandLine( (SvnScmProviderRepository) repo,
> fileSet.getBasedir(), version );
> {code}
> Should not we use {{fileSet}} instead of {{fileSet.getBaseDir()}} ?
> The {{SvnCheckInCommand()}} is using for instance the {{fileSet}} only
> {code}
> Commandline cl = createCommandLine( (SvnScmProviderRepository) repo,
> fileSet, messageFile );
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-419) Maven Subversion provider get confused by -Dusername= parameter when doing a release:prepare (Tagging operation)
[
https://jira.codehaus.org/browse/SCM-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-419:
---
Description:
I am building from a branch of a project with the SCM URL defined as
{code:xml}
svn+ssh://localhost/example/svn/services/tag-test/branches/1.0.0
{code}
I have not defined {{}}
If I do not pass the {{-Dusername=}} parameter
I can successfully do:
- {{mvn release:prepare}}
- {{mvn release:perform}}
However if I set the {{-Dusername=MYUSERNAME}} to the same username as I am
logged in as the {{release:prepare}} step fails with:
{noformat}
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: Source url
'svn+ssh://localhost/example/svn/services/tag-test/branches/1.0.0' is from
different repository
{noformat}
Based on what is committed to svn this appears to be occurring when the release
plugin is trying to perform the tagging operation.
NOTE: The command line version of svn (version 1.4.4) also gets confused when
passed two urls (one with and one without a username) :
{noformat}
svn copy svn+ssh://localhost/example/...
svn+ssh://MY_USERNAME@localhost/example/...
svn: Source and dest appear not to be in the same repository (
{noformat}
Hence I suspect that in order to fix this issue it will be necessary to
consider the source of the copy when building the target URL for the tagging
operation.
was:
I am building from a branch of a project with the SCM URL defined as
svn+ssh://localhost/example/svn/services/tag-test/branches/1.0.0
I have not defined
If I do not pass the -Dusername= parameter
I can successfully do:
- mvn release:prepare
- mvn release:perform
However if I set the -Dusername=MYUSERNAME to the same username as I am logged
in as the release:prepare step fails with:
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: Source url
'svn+ssh://localhost/example/svn/services/tag-test/branches/1.0.0' is from
different repository
Based on what is committed to svn this appears to be occurring when the release
plugin is trying to perform the tagging operation.
NOTE: The command line version of svn (version 1.4.4) also gets confused when
passed two urls (one with and one without a username) :
svn copy svn+ssh://localhost/example/...
svn+ssh://MY_USERNAME@localhost/example/...
svn: Source and dest appear not to be in the same repository (
Hence I suspect that in order to fix this issue it will be necessary to
consider the source of the copy when building the target URL for the tagging
operation.
> Maven Subversion provider get confused by -Dusername= parameter when doing a
> release:prepare (Tagging operation)
>
>
> Key: SCM-419
> URL: https://jira.codehaus.org/browse/SCM-419
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 2.0
> Environment: Maven 2.0.9
> Mac OSX
> JDK 1.5.0_13-119
> Using svn+ssh with private/public key authentication
>Reporter: David Trott
>
> I am building from a branch of a project with the SCM URL defined as
> {code:xml}
> svn+ssh://localhost/example/svn/services/tag-test/branches/1.0.0
> {code}
> I have not defined {{}}
> If I do not pass the {{-Dusername=}} parameter
> I can successfully do:
> - {{mvn release:prepare}}
> - {{mvn release:perform}}
> However if I set the {{-Dusername=MYUSERNAME}} to the same username as I am
> logged in as the {{release:prepare}} step fails with:
> {noformat}
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to tag SCM
> Provider message:
> The svn tag command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: Source url
> 'svn+ssh://localhost/example/svn/services/tag-test/branches/1.0.0' is from
> different repository
> {noformat}
> Based on what is committed to svn this appears to be occurring when the
> release plugin is trying to perform the tagging operation.
> NOTE: The command line version of svn (version 1.4.4) also gets confused when
> passed two urls (one with and one without a username) :
> {noformat}
> svn copy svn+ssh://localhost/example/...
> svn+ssh://MY_U
[jira] (SCM-538) mvn reactor:make-scm-changes fails for git provider with local git index
[
https://jira.codehaus.org/browse/SCM-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg closed SCM-538.
-
Resolution: Not A Bug
we still got no answer whether the url really was "file:.." or if the two dots
were just a placeholder for the real URL. Thus I'm closing this now as illegal.
> mvn reactor:make-scm-changes fails for git provider with local git index
>
>
> Key: SCM-538
> URL: https://jira.codehaus.org/browse/SCM-538
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.3
> Environment: windows cygwin
>Reporter: Shankar Narayan
>Assignee: Mark Struberg
>
> I have the following scm connection setup
> {code:xml}
>
> scm:git:file:..
> scm:git:file:..
> scm:git:file:..
>
> {code}
> Regular {{mvn scm:*}} commands work fine.
> The maven reactor plugin seems to have a problem when I issue the following
> command:
> {{mvn -X reactor:make-scm-changes}}
> It complains about invalid scm url. The stack trace seems to point to the
> scm-provider.
> {noformat}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't configure
> SCM repository: The scm url is invalid.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Couldn't configure
> SCM repository: The scm url is invalid.
> at
> org.apache.maven.plugin.reactor.MakeScmChanges.execute(MakeScmChanges.java:88)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.scm.repository.ScmRepositoryException: The scm
> url is invalid.
> at
> org.apache.maven.scm.provider.git.AbstractGitScmProvider.makeProviderScmRepository(AbstractGitScmProvider.java:93)
> at
> org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:192)
> at
> org.apache.maven.plugin.reactor.MakeScmChanges.execute(MakeScmChanges.java:83)
> ... 19 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-981) Surefire hangs if forked test name ends with carriage return
Christopher Mosher created SUREFIRE-981: --- Summary: Surefire hangs if forked test name ends with carriage return Key: SUREFIRE-981 URL: https://jira.codehaus.org/browse/SUREFIRE-981 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.14 Environment: linux, maven 3.0.5, jdk 1.7.0._17 Reporter: Christopher Mosher Priority: Minor Attachments: mvn_hang.tar.gz Using Spock @Unroll, you can create a test whose name ends with a carriage return. After Surefire runs this test, it hangs. To reproduce, untar the attached mvn_hang.tar.gz, cd into mvn_hang directory, and run "mvn test". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[ https://jira.codehaus.org/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323287#comment-323287 ] Mark Struberg commented on SCM-714: --- Hi Felix! Please note that scm:add != git-add and scm:checkin != git-commit maven-scm is intended to work the same way on every SCM. Thus we 'mimic' svn and cvs like operations. In the maven-release-manager we already do some special things for GIT. We'd need to There is of course an option to move the 'splitting' of git-add to an own function internally and utilize this from the other operations which need it. > mvn release:prepare fails if the command line is too long on windows > > > Key: SCM-714 > URL: https://jira.codehaus.org/browse/SCM-714 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.8.1 >Reporter: Felix Simmendinger >Priority: Blocker > > The issue from SCM-697 does not solve the issue as the gitprovider is not > using the add command but the checkin command during a release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
