[jira] (MRELEASE-867) The release:prepare doesn't commit pom.xml changes
[
https://jira.codehaus.org/browse/MRELEASE-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Lecharpentier closed MRELEASE-867.
-
Resolution: Duplicate
You were right. It is a duplication of MRELEASE-812. I didn't see this issue
before.
Adding
{code:xml}
org.apache.maven.scm
maven-scm-provider-gitexe
1.9
{code}
to my pom.xml made the job. Thanks!
> The release:prepare doesn't commit pom.xml changes
> --
>
> Key: MRELEASE-867
> URL: https://jira.codehaus.org/browse/MRELEASE-867
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.4.2
> Environment: Mac, maven-3.2.1, git-1.9.0
>Reporter: Adrien Lecharpentier
>
> Hi,
> the plugin seems not to commit the changes to the pom when upgrading the
> version. At first I thought it was the same issue than
> http://jira.codehaus.org/browse/MRELEASE-830 but in my log, I clearly see
> that the plugin doesn't commit the files:
> {code}
> [INFO] Executing: /bin/sh -c cd /Users/adrien/***/***-jira && git add --
> pom.xml
> [INFO] Working directory: /Users/adrien/***/***-jira
> [INFO] Executing: /bin/sh -c cd /Users/adrien/***/***-jira && git status
> [INFO] Working directory: /Users/adrien/***/***-jira
> [INFO] Tagging release with the label ***-1.0.2...
> [INFO] Executing: /bin/sh -c cd /Users/adrien/***/***-jira && git tag -F
> /var/folders/z9/chxs95dn61j18jrs0nb18c54gn/T/maven-scm-1442291122.commit
> ***-1.0.2
> [INFO] Working directory: /Users/adrien/***/***
> [INFO] Executing: /bin/sh -c cd /Users/adrien/***/***-jira && git push
> g...@github.com:Zenika/codesonar-plugin.git ***-1.0.2
> [INFO] Working directory: /Users/adrien/***/***-jira
> [INFO] Executing: /bin/sh -c cd /Users/adrien/***/***-jira && git ls-files
> [INFO] Working directory: /Users/adrien/***/***-jira
> [INFO] Transforming 'Jenkins CodeSonar Plugin'...
> [INFO] Not removing release POMs
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /Users/adrien/***/***-jira && git add --
> pom.xml
> [INFO] Working directory: /Users/adrien/***/***-jira
> [INFO] Executing: /bin/sh -c cd /Users/adrien/***/***-jira && git status
> [INFO] Working directory: /Users/adrien/***/***-jira
> [INFO] Release preparation complete.
> {code}
> First, it add the pom, then do a tag and finally push it. The staged pom is
> never commit. Which is strange is that the "git status" should tell the
> plugin that there is a "uncommited changed".
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-209) Incremental compilation doesn't work unless useIncrementalCompilation is set to 'false'
[
https://jira.codehaus.org/browse/MCOMPILER-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342388#comment-342388
]
Rade Martinovic commented on MCOMPILER-209:
---
This is quite unpleasant bug for me, it increases the overall time of
compilation since I am forced to do {{clean compile}} each time I do the
project build.
The workaround of setting {{useIncrementalCompilation}} to {{false}} seems to
help.
> Incremental compilation doesn't work unless useIncrementalCompilation is set
> to 'false'
> ---
>
> Key: MCOMPILER-209
> URL: https://jira.codehaus.org/browse/MCOMPILER-209
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Michael Ekstrand
>
> The compiler plugin has the
> [useIncrementalCompilation|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#useIncrementalCompilation]
> flag. However, when this flag is set to {{true}} and using the {{javac}}
> compiler, the compilation is not very incremental; the compiler always at
> least claims it is rebuilding all source files (and compile times are
> consistent with this being what it is actually doing, though it is hard to
> tell). If I set {{useIncrementalCompilation}} to {{false}}, then it actually
> does report that some modules are up-to-date, and some only need a subset of
> their files compiled.
> It seems that one or more of the following is happening:
> * {{useIncrementalCompilation}} has some meaning that is very different from
> what a user would expect, actually controlling whether the compiler plugin
> uses some internal incremental compilation mechanism vs. incremental
> compilation support built-in to the particular compiler backend. One would
> expect this flag to turn on incremental compilation vs. build-everything.
> * The log messages do not reflect what it is actually doing; that is, it
> seems possible that it's saying "Compiling 164 source files" when it's really
> handing 164 source files off to the compiler for potential compilation. If
> this is the case, it is very confusing and misleading.
> * The logic of {{useIncrementalCompilation}} is just inverted. Looking at
> the source code for the abstract compiler MOJO, it doesn't look like it's
> quite this simple, but I also don't know what all the various components at
> work are doing.
> * There is a bug in the implementation of {{useIncrementalCompilation}}.
> The result of all this is incremental compilation with Maven is very
> confusing and difficult to understand.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342396#comment-342396
]
Chris Wesdorp edited comment on MNG-5435 at 3/4/14 3:30 PM:
On my environment I encounter the same issue in combination with the
maven-checkstyle-plugin. The work around seems to be to remove all the state
files (lastUpdated) from the m2 repo folder that holds my JAR file. The
workaround for now is to use the maven dependency plugin to extract the
checkstyle.xml from the other JAR.
I use Maven 3.0.3 but it also happens with 3.1.1.
Are the any clues to where the case of this issue can be found?
was (Author: chriswesdorp):
On my environment I encounter the same issue in combination with the
maven-checkstyle-plugin. The work around seems to be to remove all the state
files (lastUpdated) from the m2 repo folder that holds my JAR file. The
workaround for now is to use the maven dependency plugin to extract the
checkstyle.xml from the other JAR.
Are the any clues to where the case of this issue can be found?
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342396#comment-342396
]
Chris Wesdorp commented on MNG-5435:
On my environment I encounter the same issue in combination with the
maven-checkstyle-plugin. The work around seems to be to remove all the state
files (lastUpdated) from the m2 repo folder that holds my JAR file. The
workaround for now is to use the maven dependency plugin to extract the
checkstyle.xml from the other JAR.
Are the any clues to where the case of this issue can be found?
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .. SUCCESS [6.835s]
> [INFO] foo-module SUCCESS [1.327s]
> [INFO] bar-module SUCCESS [0.090s]
> [INFO] baz-module FAILURE [0.012s]
> This seems to avoid issue #1 as it doesn't complain about missing Antlr
> artifacts anymore but it gets stuck on the baz-module with the error:
> [ERROR] Failed to execute goal on project baz-module: Could not resolve
> dependencies for project com.acme:
[jira] (SUREFIRE-1067) Nested causes conflated with wrapper exception
Jesse Glick created SUREFIRE-1067:
-
Summary: Nested causes conflated with wrapper exception
Key: SUREFIRE-1067
URL: https://jira.codehaus.org/browse/SUREFIRE-1067
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.13
Environment: JDK 7u51 on Linux
Reporter: Jesse Glick
Priority: Critical
I created a simple Maven project containing just a test
{code}
package p;
import java.io.IOException;
import org.junit.Test;
public class SomeTest {
@Test public void t() throws Exception {
try {
m();
} catch (RuntimeException x) {
throw new IOException(x);
}
}
private void m() {
throw new UnsupportedOperationException();
}
}
{code}
If I run this using {{maven-surefire-plugin}} 2.12.4, I get a
{{p.SomeTest.txt}} with the expected output:
{code:none}
---
Test set: p.SomeTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.037 sec <<<
FAILURE!
t(p.SomeTest) Time elapsed: 0.009 sec <<< ERROR!
java.io.IOException: java.lang.UnsupportedOperationException
at p.SomeTest.t(SomeTest.java:9)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.UnsupportedOperationException
at p.SomeTest.m(SomeTest.java:13)
at p.SomeTest.t(SomeTest.java:7)
... 29 more
{code}
But if I use 2.13 or higher, I get
{code:none}
---
Test set: p.SomeTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.037 sec <<<
FAILURE!
t(p.SomeTest) Time elapsed: 0.009 sec <<< ERROR!
java.io.IOException: java.lang.UnsupportedOperationException
at p.SomeTest.m(SomeTest.java:13)
at p.SomeTest.t(SomeTest.java:7)
{code}
which is missing the potentially crucial information about what threw the
{{IOException}} and why. (Or if the wrapper exception does not follow the
convention of appending {{": " + cause}} to its own {{message}}, the Surefire
output would lack any information about the detail message in the original
exception.)
--
This message was sent by Atlassian JIRA
(v6
[jira] (MRELEASE-682) support for git svn
[ https://jira.codehaus.org/browse/MRELEASE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MRELEASE-682: -- Fix Version/s: (was: 2.5) Backlog > support for git svn > --- > > Key: MRELEASE-682 > URL: https://jira.codehaus.org/browse/MRELEASE-682 > Project: Maven Release Plugin > Issue Type: Improvement > Components: Git >Affects Versions: 2.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: Backlog > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-581) Git relative pathing broken with release plugin
[
https://jira.codehaus.org/browse/MRELEASE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MRELEASE-581:
--
Fix Version/s: (was: 2.5)
Backlog
> Git relative pathing broken with release plugin
> ---
>
> Key: MRELEASE-581
> URL: https://jira.codehaus.org/browse/MRELEASE-581
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0
> Environment: windows xp, service pack 2
>Reporter: Matthew Sandoz
>Assignee: Mark Struberg
> Fix For: Backlog
>
> Attachments: gitexe.zip, MRELEASE-581.patch
>
>
> i have a multimodule project, and when i try to do a release, i get
> everything working fine until the end. It seems to think for some reason that
> I am at the root of my scm tree. The repo i have to work in has several
> projects, and mine is in a subdirectory - domains/redemption. the plugin
> appears to try to check in my submodules at my current location instead of my
> scm root.
> COMMAND:
> {{mvn release:prepare -DpreparationGoals="clean install" -DskipTests
> -DautoVersionSubmodules=true}}
> {noformat}
> END OF OUTPUT:
> [INFO] [INFO] Reactor Summary:
> [INFO] [INFO]
>
> [INFO] [INFO] Redemption Parent POM . SUCCESS
> [2.595s]
> [INFO] [INFO] Redemption Runtime Confguration ... SUCCESS
> [3.531s]
> [INFO] [INFO] Redemption Service Metadata ... SUCCESS
> [18.816s]
> [INFO] [INFO] Redemption Model .. SUCCESS
> [35.693s]
> [INFO] [INFO] Redemption DAO SUCCESS
> [41.770s]
> [INFO] [INFO] Redemption Service Implementation . SUCCESS
> [17.517s]
> [INFO] [INFO] crm :: guest :: redemption :: ESB :: Parent POM ... SUCCESS
> [0.016s]
> [INFO] [INFO] crm :: guest :: redemption :: ESB :: XSLT . SUCCESS
> [5.469s]
> [INFO] [INFO] crm :: guest :: redemption :: ESB :: EIP .. SUCCESS
> [0.343s]
> [INFO] [INFO] crm :: guest :: redemption :: ESB :: Version Router ... SUCCESS
> [3.157s]
> [INFO] [INFO] crm :: guest :: redemption :: ESB :: Binding Component ::
> Service Unit SUCCESS [3.656s]
> [INFO] [INFO] crm :: guest :: redemption :: ESB :: Service Assembly . SUCCESS
> [3.516s]
> [INFO] [INFO]
>
> [INFO] [INFO]
>
> [INFO] [INFO] BUILD SUCCESSFUL
> [INFO] [INFO]
>
> [INFO] [INFO] Total time: 2 minutes 26 seconds
> [INFO] [INFO] Finished at: Tue Jul 27 17:18:02 EDT 2010
> [INFO] [INFO] Final Memory: 116M/254M
> [INFO] [INFO]
>
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add pom.xml redemption-conf\pom.xml
> redemption-metadata\pom.xml redemption-model\pom.xml rede
> mption-dao\pom.xml redemption-impl\pom.xml redemption-esb\pom.xml
> redemption-esb\redemption-xslt\pom.xml redemption-esb\redemption
> -eip\pom.xml redemption-esb\redemption-router\pom.xml
> redemption-esb\redemption-bc-su\pom.xml redemption-esb\redemption-sa\pom.xml
> "
> [INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
> [INFO] Executing: cmd.exe /X /C "git status"
> [INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
> [INFO] Executing: cmd.exe /X /C "git commit --verbose -F
> D:\DOCUME~1\sandozm\LOCALS~1\Temp\maven-scm-1862033505.commit pom.xml red
> emption-conf\pom.xml redemption-metadata\pom.xml redemption-model\pom.xml
> redemption-dao\pom.xml redemption-impl\pom.xml redemptio
> n-esb\pom.xml redemption-esb\redemption-xslt\pom.xml
> redemption-esb\redemption-eip\pom.xml redemption-esb\redemption-router\pom.xm
> l redemption-esb\redemption-bc-su\pom.xml
> redemption-esb\redemption-sa\pom.xml"
> [INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to commit files
> Provider message:
> The git-commit command failed.
> Command output:
> error: pathspec 'redemption-conf\pom.xml' did not match any file(s) known to
> git.
> error: pathspec 'redemption-metadata\pom.xml' did not match any file(s) known
> to git.
> error: pathspec 'redemption-model\pom.xml' did not match any file(s) known to
> git.
> error: pathspec 'redemption-dao\pom.xml' did not match any file(s) known to
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MRELEASE-431: -- Fix Version/s: (was: 2.5) Backlog > Configuration of policy for calculating next (release) version > -- > > Key: MRELEASE-431 > URL: https://jira.codehaus.org/browse/MRELEASE-431 > Project: Maven Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-8 >Reporter: Carsten Ziegeler >Assignee: Robert Scholte > Fix For: Backlog > > Attachments: > 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch, > MRELEASE-431.patch, MRELEASE-431-v2.patch, MRELEASE-431-v3.patch > > > Currently, when preparing the release, the version to release is always the > next version which usually is the current version without the snapshot > extension. > There are quiet a lot projects (Apache Felix, Sling and others) following an > even release numbering policy. So while the current development version is > odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4. > It would be nice if this could be made configuration through some > configuration property like > next-even (with possible values being: next > (default, as-is), next-even, next-odd > I briefly scanned through the code and it seems that adding support for this > requires changes in both, the release-manager and the release-plugin. > If this feature gets accepted and if someone could give me some minor hints > how/where to add this I could come up with a patch. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-166) release:prepare should always check for local modifications
[ https://jira.codehaus.org/browse/MRELEASE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MRELEASE-166: -- Fix Version/s: (was: 2.5) Backlog > release:prepare should always check for local modifications > --- > > Key: MRELEASE-166 > URL: https://jira.codehaus.org/browse/MRELEASE-166 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-4 >Reporter: Jörg Schaible >Priority: Critical > Fix For: Backlog > > > If the first call to release:prepare fails, it does not check again for local > modifications. This is quite likely though, since the release manager might > have cleared the erroneous condition. If he forgets to check, the labe is set > to the wrong version of the files and release:perform fails. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-263) Interactive plugins cannot work in forked executions
[ https://jira.codehaus.org/browse/MRELEASE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MRELEASE-263: -- Fix Version/s: (was: 2.5) Backlog > Interactive plugins cannot work in forked executions > > > Key: MRELEASE-263 > URL: https://jira.codehaus.org/browse/MRELEASE-263 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-6 >Reporter: Daniel Kulp >Priority: Critical > Fix For: Backlog > > > I was looking into the problems with the GPG plugin when run from the > release plugin and the problems seem to entirely be problems of the > release plugin and Plexus utils. They are showing up in the gpg > plugin, but any plugin that tries to do anything interactively would > most likely run into the same problems. > Issues: > 1) System.in - the release manager doesn't feed anything from System.in > into the forked process. I tried adding System.in to the > CommandLineUtils.executeCommandLine call, but that just causes a hang. > CommandLineUtils will wait until the "in" stream is completely consumed > (returns -1) before returning. With System.in, that never will happen. > 2) Buffered(line style) out - the StreamPumpers use > BufferedInputStream.readLine() to pump from one stream to the other. > This won't work. Anything that does something (like the release plugin > itself) that prompts and then waits for a response on the same line will > appear to just "hang" as the prompt will never make it to the screen. > Basically, those two issues completely prevent us from being able to > un-hard code GPG passphrases from build scripts and such. (unless you > set gpg.useagent to true and use an agent) > In anycase, MGPG-9 is really a release plugin bug although part of it is > due to plexus-utils not providing the support it would need to work > properly.Most likely, we'll need to add a method in CommandLineUtils > that would just take the raw streams (in/out/err) and do straight byte > copy reads without the line buffering. (and once the process > completely, stop pumping the in stream) (of course, that would then > require another plexus-utils release and then the release plugin would > only work with Maven 2.0.6+ with the utils shaded, but that may be > minor) I'll poke around more and see if I can come up with something. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-719) No error when release:prepare with an already existing scm tag
[ https://jira.codehaus.org/browse/MRELEASE-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MRELEASE-719: -- Fix Version/s: (was: 2.5) Backlog > No error when release:prepare with an already existing scm tag > -- > > Key: MRELEASE-719 > URL: https://jira.codehaus.org/browse/MRELEASE-719 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.1 >Reporter: Tony Chemit >Assignee: Olivier Lamy > Fix For: Backlog > > > When releasing the mojo-parent (codehaus), I had to do the release twice but > I forgot to remove the scm tag. > The release:prepare did not complain about it (should have). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-753) Upgrade to JUnit 4.x
[
https://jira.codehaus.org/browse/MRELEASE-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MRELEASE-753:
--
Fix Version/s: (was: 2.5)
Backlog
> Upgrade to JUnit 4.x
>
>
> Key: MRELEASE-753
> URL: https://jira.codehaus.org/browse/MRELEASE-753
> Project: Maven Release Plugin
> Issue Type: Task
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: Backlog
>
> Attachments: release_junit4.diff
>
>
> I'd like to use some JUnit4-features, especially for the {{ReleasePhase}}
> tests, but these now extend {{PlexusTestCase}}.
> PLX-446 still hasn't been implemented and we're still on a pretty old version
> of the plexus-container.
> So there are several steps which have to be taken. Depending on the order,
> I'll attach a {{PlexusJUnit4TestCase}} class, which should make it a bit
> easier to move to JUnit4.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-356) deprecate the automated release profile
[ https://jira.codehaus.org/browse/MRELEASE-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MRELEASE-356: -- Fix Version/s: (was: 2.5) Backlog > deprecate the automated release profile > --- > > Key: MRELEASE-356 > URL: https://jira.codehaus.org/browse/MRELEASE-356 > Project: Maven Release Plugin > Issue Type: Task > Components: perform >Reporter: Brett Porter > Fix For: Backlog > > > the release profile is being removed from the super POM in Maven 2.1-alpha-1, > so the release plugin should pre-emptively start ensuring users do this > themselves -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-221) ResourceIncludes default value is wrong
Arlo Louis O'Keeffe created MCHECKSTYLE-221: --- Summary: ResourceIncludes default value is wrong Key: MCHECKSTYLE-221 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-221 Project: Maven Checkstyle Plugin Issue Type: Bug Affects Versions: 2.11 Reporter: Arlo Louis O'Keeffe Priority: Minor The default value for resourceIncludes is supposed to be **\/*.properties but in fact it is **/*.properties. You can verify in the generated maven site: https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#resourceIncludes An easy workaround is to simply define resourceIncludes yourself. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-221) ResourceIncludes default value is wrong
[ https://jira.codehaus.org/browse/MCHECKSTYLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arlo Louis O'Keeffe updated MCHECKSTYLE-221: Description: The default value for resourceIncludes is supposed to be \*\*\/\*.properties but in fact it is \*\*/\*.properties. You can verify in the generated maven site: https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#resourceIncludes An easy workaround is to simply define resourceIncludes yourself. was: The default value for resourceIncludes is supposed to be **\/*.properties but in fact it is **/*.properties. You can verify in the generated maven site: https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#resourceIncludes An easy workaround is to simply define resourceIncludes yourself. > ResourceIncludes default value is wrong > --- > > Key: MCHECKSTYLE-221 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-221 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.11 >Reporter: Arlo Louis O'Keeffe >Priority: Minor > > The default value for resourceIncludes is supposed to be \*\*\/\*.properties > but in fact it is \*\*/\*.properties. > You can verify in the generated maven site: > https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#resourceIncludes > An easy workaround is to simply define resourceIncludes yourself. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
