[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 ] Robert Munteanu updated MRELEASE-431: - Attachment: MRELEASE-431-v3.patch > 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: 2.5 > > 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 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-431) Configuration of policy for calculating next (release) version
[ https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332905#comment-332905 ] Robert Munteanu commented on MRELEASE-431: -- [~rfscholte] - I've attached [^MRELEASE-431-v3.patch], with the VersionPolicyRequest addition ( [diff on github|https://github.com/rombert/release/compare/6de575dd76224c690bfd88375eac88f49ba6d319...HEAD] ). > 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: 2.5 > > 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 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-594) release:prepare should stop when there is snapshots in dependencies management
[ https://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Foegen updated MRELEASE-594: --- Attachment: allowUnusedSnapshotsInDependencyManagement.patch Hi, please have a look at the patch I've attached. By default the behaviour of the plugin remains the same but it can be "enabled" by adding the following flag -DallowUnusedSnapshotsInDependencyManagement=false (the default is true). If enabled, it treats snapshots in the dependency management section the same way as snapshots in the dependency section, i.e. snapshots can be resolved or the release fails. > release:prepare should stop when there is snapshots in dependencies management > -- > > Key: MRELEASE-594 > URL: https://jira.codehaus.org/browse/MRELEASE-594 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Reporter: Thomas Bruyelle >Assignee: Olivier Lamy > Fix For: Backlog > > Attachments: allowUnusedSnapshotsInDependencyManagement.patch > > -- 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-594) release:prepare should stop when there is snapshots in dependencies management
[ https://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332916#comment-332916 ] Hans Aikema commented on MRELEASE-594: -- I agree with previous commenters that DISallowing snapshots in dependencies in the release of any project should be the default (breaking backward stability in favor of forward build stability as no-one can predict what will change in the snapshot version after the release of the POM, making projects that safeguard their maintenance on 'latest released' version of a parent still run the risk of breaking builds/releases). A released parent POM should by default give a stable development environment to build and release on. A snapshot parent POM may introduce all kinds of dependency-caused breaking software. Snapshot-versions of dependencies introduced by a released parent-POM breaking your release cycle is completely counter-intuitive to the meaning of stable artefacts in Maven. > release:prepare should stop when there is snapshots in dependencies management > -- > > Key: MRELEASE-594 > URL: https://jira.codehaus.org/browse/MRELEASE-594 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Reporter: Thomas Bruyelle >Assignee: Olivier Lamy > Fix For: Backlog > > Attachments: allowUnusedSnapshotsInDependencyManagement.patch > > -- 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-594) release:prepare should stop when there is snapshots in dependencies management
[ https://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332916#comment-332916 ] Hans Aikema edited comment on MRELEASE-594 at 9/17/13 9:23 AM: --- I agree with previous commenters that DISallowing snapshots in dependencies in the release of any project should be the default (breaking backward compatibility in favor of forward build stability as no-one can predict what will change in the snapshot version after the release of the POM, making projects that safeguard their maintenance on 'latest released' version of a parent still run the risk of breaking builds/releases). A released parent POM should by default give a stable development environment to build and release on. A snapshot parent POM may introduce all kinds of dependency-caused breaking software. Snapshot-versions of dependencies introduced by a released parent-POM breaking your release cycle is completely counter-intuitive to the meaning of stable artefacts in Maven. was (Author: aikebah): I agree with previous commenters that DISallowing snapshots in dependencies in the release of any project should be the default (breaking backward stability in favor of forward build stability as no-one can predict what will change in the snapshot version after the release of the POM, making projects that safeguard their maintenance on 'latest released' version of a parent still run the risk of breaking builds/releases). A released parent POM should by default give a stable development environment to build and release on. A snapshot parent POM may introduce all kinds of dependency-caused breaking software. Snapshot-versions of dependencies introduced by a released parent-POM breaking your release cycle is completely counter-intuitive to the meaning of stable artefacts in Maven. > release:prepare should stop when there is snapshots in dependencies management > -- > > Key: MRELEASE-594 > URL: https://jira.codehaus.org/browse/MRELEASE-594 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Reporter: Thomas Bruyelle >Assignee: Olivier Lamy > Fix For: Backlog > > Attachments: allowUnusedSnapshotsInDependencyManagement.patch > > -- 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
Maven parsing pom.xml incorrectly
I'm using Thrift in my Maven project, compiling my .thrift code to .java as part of the generate-sources step. To do this, I use the maven antrun plugin in my pom.xml, which executes a command line call to the thrift executable, and sends it the appropriate argument flags, such as "-out" and "--gen". However, when I comment out this plugin with the standard XML comment syntax , Maven fails to parse the pom file. It doesn't like the fact that the comment contains --gen, expecting the comment to end right there. Can we please improve Maven's comment syntax parsing for pom.xml?
[jira] (MJARSIGNER-13) signing in multi-module project fails on windows
[
https://jira.codehaus.org/browse/MJARSIGNER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332937#comment-332937
]
Chris Feldhacker commented on MJARSIGNER-13:
Possibly related tidbit to consider:
We have Windows scripts to install various IDEs and local servers, which
involves using keytool.exe to import needed certificates into keystores. When
we ran the imports back-to-back, it would fail with files in use (sometime it
would just hang).
What we found was we had to impose a 3-5 second delay between commands before
they would work. Don't know if its a Windows issue or perhaps an issue with
some of the JDK tools, but perhaps something similar is happening here...
Would be nice to at least have the option to NOT rename the file to .orig
before signing...
> signing in multi-module project fails on windows
>
>
> Key: MJARSIGNER-13
> URL: https://jira.codehaus.org/browse/MJARSIGNER-13
> Project: Maven Jar Signer Plugin
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows XP, android sdk
>Reporter: Anna Gadomska
> Attachments: pom.xml
>
>
> I got multi-module (6 modules) android project with .pom file and "sign"
> profile defined. When I execute with 'sign' profile:
> - in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution
> (mv -rf) it signs another 3 modules and fails again. The reason for
> failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig
> failed.
> - in Maven 2.2.1 - it doesn't work at all, even for first module; it returns
> "error code 1"
> However, I tried the same .pom - everything works perfectly in Linux
> (Ubuntu).
> I was afraid that it might be the issue with spaces, so I hardcoded the paths
> - the error I got from maven than was:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project
> MyProject: Failed executing 'cmd.exe /X /C
> "C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore
> "C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar
> '*'debugkey"' - exitcode 1 -> [Help 1]
> {noformat}
> Attaching pom file which I am using.
> Please help?
--
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] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.
[ https://jira.codehaus.org/browse/MSITE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332939#comment-332939 ] Christian Schulte commented on MSITE-665: - Could someone please perform a release of the site plugin with the attached patch applied ? It is a regression and is blocking the upgrade to Maven 3.1.x. > Site plugin version 3.2 seems to modify a project's classpath. > -- > > Key: MSITE-665 > URL: https://jira.codehaus.org/browse/MSITE-665 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.2 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Java version: 1.7.0_03, vendor: Oracle Corporation >Reporter: Christian Schulte > Attachments: MSITE-665.patch, MSITE-665.zip, msp-3.1.log, msp-3.2.log > > -- 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
bug in parsing file ... comments
We ran into a parsing bug that prevents commenting out an option with a command line for maven. We tried commenting out (for testing purposes) the following plugin, which contains the "thrift --gen" command. The "--gen" caused a parse error in the file (looks like it thinks it needs to have --> because it is in a comment rather than --> as the only thing that matters. It would be *great* if it allowed nesting of comments, but I'll take that it just doesn't barf on valid command structures. Because the following is a comment, you *should* be able to paste it into any pom file and have maven process the file properly.
