[jira] (MNG-612) implement conflict resolution techniques
[ https://jira.codehaus.org/browse/MNG-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343188#comment-343188 ] Benjamin Podgursky commented on MNG-612: Sorry to jump on an ancient ticket, but could you point me to how to modify this behavior via Aether? For context, I'm moving a bunch of projects from ivy to maven dependency declarations, and it would be really helpful to at least temporarily emulate ivy's "always choose newest" behavior so I don't have to manually hunt through the dependency lists to make sure nothing is getting a different version than it used to... > implement conflict resolution techniques > > > Key: MNG-612 > URL: https://jira.codehaus.org/browse/MNG-612 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Artifacts and Repositories, Design, Patterns & Best > Practices >Reporter: Brett Porter >Assignee: Mark Hobson >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: MNG-612-2.patch, MNG-612-3.patch, MNG-612.patch > > Original Estimate: 8 hours > Remaining Estimate: 8 hours > > currently, the collector only: > - selects nearest "suggested" version in a valid range > - latest version from the valid ranges if none suggested > - fails if ranges are over-constrained > This needs to be configurable: > - select newest, even if there is a nearer suggestion > - select oldest, even if there is a nearer suggestion > - fail if all suggestions don't equate or a range results instead of a single > version > - ignore over constrained ranges and fallback to some other algorithm > - select snapshots even if they weren't explicitly specified -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-369) New goals javadoc-no-fork and test-javadoc-no-fork which will not invoke generate-*-sources
[
https://jira.codehaus.org/browse/MJAVADOC-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirko Friedenhagen updated MJAVADOC-369:
Affects Version/s: 2.9.1
> New goals javadoc-no-fork and test-javadoc-no-fork which will not invoke
> generate-*-sources
> ---
>
> Key: MJAVADOC-369
> URL: https://jira.codehaus.org/browse/MJAVADOC-369
> Project: Maven Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.9, 2.9.1
>Reporter: Mirko Friedenhagen
>Assignee: Mirko Friedenhagen
> Attachments: mjavadoc-369.patch
>
>
> * We have a lot of projects in our CI system (Jenkins) where we run {{mvn
> clean deploy site-deploy}}.
> * Because of this, the phase {{generate-sources}} resp.
> {{generate-test-sources}} does not need to rerun. It might even give a
> different result from the previous run during the default lifecycle.
> * Attached is a patch (including a IT) which will introduce two new goals,
> {{javadoc-no-fork}} and {{test-javadoc-no-fork}}, which will just skip the
> fork during site-run.
> In our case, e.g. {{enforcer:enforce}}, {{jacoco:prepare-agent}} and a
> homegrown configuration plugin are executed over and over again, which:
> * leads to confusion when application developers look on the console and
> * slows down the builds.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-325) maven-filtering 1.2 throws MavenFilteringException: Mark invalid
[
https://jira.codehaus.org/browse/MSHARED-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MSHARED-325:
---
Attachment: MSHARED-325-tests.patch
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid
>
>
> Key: MSHARED-325
> URL: https://jira.codehaus.org/browse/MSHARED-325
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.2
>Reporter: Mikolaj Izdebski
> Attachments: 0001-Add-unit-test-for-MSHARED-325.patch,
> MSHARED-325-tests.patch, payload
>
>
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid on some
> resource files, which filtering is successfull with version 1.1.
> An example payload is attached. I will attach a reproducer as a unit test
> too.
> {code}
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
> invalid
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:301)
> ... 21 more
> Caused by: java.io.IOException: Mark invalid
> at java.io.BufferedReader.reset(BufferedReader.java:505)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
> at java.io.Reader.read(Reader.java:140)
> at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
> at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
> ... 23 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-325) maven-filtering 1.2 throws MavenFilteringException: Mark invalid
[
https://jira.codehaus.org/browse/MSHARED-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343185#comment-343185
]
Robert Scholte commented on MSHARED-325:
Found the cause: the Reader has collected more characters then the
readAheadLimit of 22 (calculated default). Increasing this value is the easy
solution until someone else hits the new limit. This used to work before the
fix of MSHARED-199.
For now, just escape such characters.
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid
>
>
> Key: MSHARED-325
> URL: https://jira.codehaus.org/browse/MSHARED-325
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.2
>Reporter: Mikolaj Izdebski
> Attachments: 0001-Add-unit-test-for-MSHARED-325.patch, payload
>
>
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid on some
> resource files, which filtering is successfull with version 1.1.
> An example payload is attached. I will attach a reproducer as a unit test
> too.
> {code}
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
> invalid
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:301)
> ... 21 more
> Caused by: java.io.IOException: Mark invalid
> at java.io.BufferedReader.reset(BufferedReader.java:505)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
> at java.io.Reader.read(Reader.java:140)
> at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
> at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
> ... 23 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-188) ReactorModuleConvergence does not print the message
[
https://jira.codehaus.org/browse/MENFORCER-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-188:
--
Fix Version/s: 1.4
> ReactorModuleConvergence does not print the message
> ---
>
> Key: MENFORCER-188
> URL: https://jira.codehaus.org/browse/MENFORCER-188
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4
> Environment: Apache Maven 3.2.1
> (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T17:37:52+00:00)
> Maven home: c:\softs\apache-maven-3.2.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: c:\softs\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Samuel Langlois
>Priority: Minor
> Fix For: 1.4
>
>
> The message that you can set in the configuration of the
> ReactorModuleConvergence rule is never displayed.
> The plugin is configured as such:
> {code}
>
>
>
> This message is never displayed
>
>
>
> {code}
> and the output in case the enforcer rule fails is:
> {code}
> [INFO] --- maven-enforcer-plugin:2.0-SNAPSHOT:enforce (enforcer) @
> alfresco-parent ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.ReactorModuleConvergence
> failed with message:
> The reactor contains different versions.
> --> org.alfresco:alfresco-data-model:jar:4.3.0-SNAPSHOT
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-186) Create a rule for the reactor (ReactorModuleConvergence)
[
https://jira.codehaus.org/browse/MENFORCER-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-186:
--
Comment: was deleted
(was: Can you please remove this comment and create a separate JIRA issue for
that. I need to check this.)
> Create a rule for the reactor (ReactorModuleConvergence)
>
>
> Key: MENFORCER-186
> URL: https://jira.codehaus.org/browse/MENFORCER-186
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4
>
>
> It would be nice having a rule which checks the consitency of a multi-module
> build.
> Say having a build with modules like this:
> {code}
> +-- root (pom.xml)
> +--- m1 (pom.xml)
>+--- m11 (pom.xml)
>+--- m12 (pom.xml)
> +--- m2 (pom.xml)
>+--- m21 (pom.xml)
>+--- m21 (pom.xml)
> +--- m3 (pom.xml)
>+--- m31 (pom.xml)
>+--- m31 (pom.xml)
> +--- m4 (pom.xml)
> +--- m5 (pom.xml)
> {code}
> If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
> But what sometimes it happens that someone changes something and you will
> find things like the following:
> The module m21 (pom.xml) has a parent version of 1.1.0-SNAPSHOT instead of
> 1.2.0-SNAPSHOT which means maven will try to find this version in repository
> (you will get a warning during the build; But who reads warnings ;-))..
> Or other things having module interdependencies and it happens someone does
> something like this:
> In m4 a dependency is written like this:
> {code}
>
>TheGroup
>m21
>1.1.0-SNAPSHOT
>
> {code}
> which will usually build (except your SNAPSHOT's have been deleted before),
> but it is not correct. or better like this:
> {code}
>
>TheGroup
>m21
>1.1.0
>
> {code}
> This means it will be solved against a released version which usually is not
> the intention in such cases.
> So the rule should check if the groupId/artifactId belongs to the reactor and
> check the consistency of the version of the dependencies etc. Also the parent
> would be nice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-325) maven-filtering 1.2 throws MavenFilteringException: Mark invalid
[
https://jira.codehaus.org/browse/MSHARED-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343171#comment-343171
]
Robert Scholte commented on MSHARED-325:
Workaround: escape the {{@}} with a backward slash
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid
>
>
> Key: MSHARED-325
> URL: https://jira.codehaus.org/browse/MSHARED-325
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.2
>Reporter: Mikolaj Izdebski
> Attachments: 0001-Add-unit-test-for-MSHARED-325.patch, payload
>
>
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid on some
> resource files, which filtering is successfull with version 1.1.
> An example payload is attached. I will attach a reproducer as a unit test
> too.
> {code}
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
> invalid
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:301)
> ... 21 more
> Caused by: java.io.IOException: Mark invalid
> at java.io.BufferedReader.reset(BufferedReader.java:505)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
> at java.io.Reader.read(Reader.java:140)
> at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
> at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
> ... 23 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-839) Unable to supply tag to release for release:perform
[ https://jira.codehaus.org/browse/MRELEASE-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343170#comment-343170 ] Tuure Laurinolli commented on MRELEASE-839: --- Yes, as I noted in MRELEASE-796. > Unable to supply tag to release for release:perform > --- > > Key: MRELEASE-839 > URL: https://jira.codehaus.org/browse/MRELEASE-839 > Project: Maven Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.4.1 >Reporter: Tuure Laurinolli > > The documentation at > http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html > and > http://maven.apache.org/maven-release/maven-release-plugin/plugin-info.html > claims that releases can be ma de of a specific tag, but no mechanism for > this is specified. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-303) Add an option to enable tls
[ https://jira.codehaus.org/browse/MCHANGES-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343169#comment-343169 ] Benoit Guerin commented on MCHANGES-303: Great ! thanks ! > Add an option to enable tls > --- > > Key: MCHANGES-303 > URL: https://jira.codehaus.org/browse/MCHANGES-303 > Project: Maven Changes Plugin > Issue Type: Improvement > Components: announcement >Affects Versions: 2.8 >Reporter: Benoit Guerin >Assignee: Dennis Lundberg > Fix For: 2.10 > > Attachments: enableTls.patch > > > Add an option to set ProjectJavamailMailSender.tlsEnabled to true, to allow > to use as an example GMail to send announcement emails -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-186) Create a rule for the reactor (ReactorModuleConvergence)
[
https://jira.codehaus.org/browse/MENFORCER-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samuel Langlois updated MENFORCER-186:
--
Comment: was deleted
(was: Thank you for this new rule! I was looking for a nasty hack to do exactly
this...
Note that currently (r1578567), the {{}} that you pass to the
configuration is not displayed when the rule fails -- but maybe you didn't code
this behaviour so far.)
> Create a rule for the reactor (ReactorModuleConvergence)
>
>
> Key: MENFORCER-186
> URL: https://jira.codehaus.org/browse/MENFORCER-186
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4
>
>
> It would be nice having a rule which checks the consitency of a multi-module
> build.
> Say having a build with modules like this:
> {code}
> +-- root (pom.xml)
> +--- m1 (pom.xml)
>+--- m11 (pom.xml)
>+--- m12 (pom.xml)
> +--- m2 (pom.xml)
>+--- m21 (pom.xml)
>+--- m21 (pom.xml)
> +--- m3 (pom.xml)
>+--- m31 (pom.xml)
>+--- m31 (pom.xml)
> +--- m4 (pom.xml)
> +--- m5 (pom.xml)
> {code}
> If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
> But what sometimes it happens that someone changes something and you will
> find things like the following:
> The module m21 (pom.xml) has a parent version of 1.1.0-SNAPSHOT instead of
> 1.2.0-SNAPSHOT which means maven will try to find this version in repository
> (you will get a warning during the build; But who reads warnings ;-))..
> Or other things having module interdependencies and it happens someone does
> something like this:
> In m4 a dependency is written like this:
> {code}
>
>TheGroup
>m21
>1.1.0-SNAPSHOT
>
> {code}
> which will usually build (except your SNAPSHOT's have been deleted before),
> but it is not correct. or better like this:
> {code}
>
>TheGroup
>m21
>1.1.0
>
> {code}
> This means it will be solved against a released version which usually is not
> the intention in such cases.
> So the rule should check if the groupId/artifactId belongs to the reactor and
> check the consistency of the version of the dependencies etc. Also the parent
> would be nice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-188) ReactorModuleConvergence does not print the message
Samuel Langlois created MENFORCER-188:
-
Summary: ReactorModuleConvergence does not print the message
Key: MENFORCER-188
URL: https://jira.codehaus.org/browse/MENFORCER-188
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.4
Environment: Apache Maven 3.2.1
(ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T17:37:52+00:00)
Maven home: c:\softs\apache-maven-3.2.1
Java version: 1.7.0_45, vendor: Oracle Corporation
Java home: c:\softs\jdk1.7.0_45\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Samuel Langlois
Priority: Minor
The message that you can set in the configuration of the
ReactorModuleConvergence rule is never displayed.
The plugin is configured as such:
{code}
This message is never displayed
{code}
and the output in case the enforcer rule fails is:
{code}
[INFO] --- maven-enforcer-plugin:2.0-SNAPSHOT:enforce (enforcer) @
alfresco-parent ---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.ReactorModuleConvergence
failed with message:
The reactor contains different versions.
--> org.alfresco:alfresco-data-model:jar:4.3.0-SNAPSHOT
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-186) Create a rule for the reactor (ReactorModuleConvergence)
[
https://jira.codehaus.org/browse/MENFORCER-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343163#comment-343163
]
Karl Heinz Marbaise commented on MENFORCER-186:
---
Can you please remove this comment and create a separate JIRA issue for that. I
need to check this.
> Create a rule for the reactor (ReactorModuleConvergence)
>
>
> Key: MENFORCER-186
> URL: https://jira.codehaus.org/browse/MENFORCER-186
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4
>
>
> It would be nice having a rule which checks the consitency of a multi-module
> build.
> Say having a build with modules like this:
> {code}
> +-- root (pom.xml)
> +--- m1 (pom.xml)
>+--- m11 (pom.xml)
>+--- m12 (pom.xml)
> +--- m2 (pom.xml)
>+--- m21 (pom.xml)
>+--- m21 (pom.xml)
> +--- m3 (pom.xml)
>+--- m31 (pom.xml)
>+--- m31 (pom.xml)
> +--- m4 (pom.xml)
> +--- m5 (pom.xml)
> {code}
> If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
> But what sometimes it happens that someone changes something and you will
> find things like the following:
> The module m21 (pom.xml) has a parent version of 1.1.0-SNAPSHOT instead of
> 1.2.0-SNAPSHOT which means maven will try to find this version in repository
> (you will get a warning during the build; But who reads warnings ;-))..
> Or other things having module interdependencies and it happens someone does
> something like this:
> In m4 a dependency is written like this:
> {code}
>
>TheGroup
>m21
>1.1.0-SNAPSHOT
>
> {code}
> which will usually build (except your SNAPSHOT's have been deleted before),
> but it is not correct. or better like this:
> {code}
>
>TheGroup
>m21
>1.1.0
>
> {code}
> This means it will be solved against a released version which usually is not
> the intention in such cases.
> So the rule should check if the groupId/artifactId belongs to the reactor and
> check the consistency of the version of the dependencies etc. Also the parent
> would be nice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-839) Unable to supply tag to release for release:perform
[
https://jira.codehaus.org/browse/MRELEASE-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343155#comment-343155
]
Joshua Spiewak commented on MRELEASE-839:
-
I think the problem may be that the other mojos were all updated to extend the
new {{AbstractScmReleaseMojo}} while {{PerformReleaseMojo}} still extends
{{AbstractReleaseMojo}}. Thus {{mvn release:perform}} does not have access to
the tag that is passed in, and the git scm provider tries to run {{git clone
--branch }}. Since the tag is missing from the command, you
get an error:
{noformat}
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: repository '/Users/jspiewak/work/bc/mrptest/target/checkout'
does not exist
{noformat}
This is still an issue with 2.5
> Unable to supply tag to release for release:perform
> ---
>
> Key: MRELEASE-839
> URL: https://jira.codehaus.org/browse/MRELEASE-839
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.4.1
>Reporter: Tuure Laurinolli
>
> The documentation at
> http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
> and
> http://maven.apache.org/maven-release/maven-release-plugin/plugin-info.html
> claims that releases can be ma de of a specific tag, but no mechanism for
> this is specified.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1069) Typo in alwaysGenerateSurefireReport doc: "Defaulyts"
Joshua Hyde created SUREFIRE-1069:
-
Summary: Typo in alwaysGenerateSurefireReport doc: "Defaulyts"
Key: SUREFIRE-1069
URL: https://jira.codehaus.org/browse/SUREFIRE-1069
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Report Plugin
Affects Versions: 2.16
Reporter: Joshua Hyde
Priority: Trivial
The documentation for the {{alwaysGenerateSurefireReport}} parameter has a typo
of "Defaults":
{quote}If set to true the surefire report will be generated even when there are
no surefire result files. Defaulyts to true to preserve legacy behaviour pre
2.10.
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-437) Create symbolic links instead of physical copies
Markus KARG created MDEP-437: Summary: Create symbolic links instead of physical copies Key: MDEP-437 URL: https://jira.codehaus.org/browse/MDEP-437 Project: Maven Dependency Plugin Issue Type: New Feature Components: copy Affects Versions: 2.8 Environment: JDK 7u51, Win 7 Pro SP1 (64 Bit) Reporter: Markus KARG When copying lots of resources, especially huge ones (e. g. we are dealing with two gigabytes (!) split up into several 100 MB large binaries) it is tedious to wait until the copy task has performed real physical copies... Since JRE 7 Java (which is public for years meanwhile) can deal with symbolic links, it would be really cool if one could add a true configuration option, so the plugin could simply go the fast lane and use symbolic links instead of physical copies. For backwards compatibility unfortunately the default has to be "false". :-( -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5602) Installs non-existent file into local repository
Markus KARG created MNG-5602: Summary: Installs non-existent file into local repository Key: MNG-5602 URL: https://jira.codehaus.org/browse/MNG-5602 Project: Maven 2 & 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 3.0.4 Environment: Win7 Pro SP1 64 Bit, JDK 7u51, MVN-INSTALL-PLUGIN 2.3.1 Reporter: Markus KARG Priority: Critical The Maven Install Plugin 2.3.1 confirms that it successfully installed a file which actually is not existing in neither the SOURCE nor the TARGET location... This is simply confusing people. Steps to reproduce: * Provide a non-existent SOURCE file to the build-helper-plugin and run mvn install. org.codehaus.mojo build-helper-maven-plugin 1.8 attach-exe package attach-artifact FOO BAR The result is an info that the file got actually installed -- which is obviously NOT the case: [INFO] Installing C:\Users\me\workspace\Bug\FOO to C:\Users\me\.m2\repository\my\group\the-artifact\version-SNAPSHOT\the-artifact-version-SNAPSHOT.BAR -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-508) Wrong scm url validation for mercurial provider
[ https://jira.codehaus.org/browse/SCM-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343127#comment-343127 ] Devin Reid commented on SCM-508: Just got bit by this one. localCheckout=true is not working on Windows. Same error as commented above. > Wrong scm url validation for mercurial provider > --- > > Key: SCM-508 > URL: https://jira.codehaus.org/browse/SCM-508 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Reporter: Alexander Nemish > Fix For: 1.x > > Attachments: SCM-508-maven-scm-provider-hg.patch > > > According to documentation (http://maven.apache.org/scm/mercurial.html) scm > url can be of this form: > scm:hg:file://C:/dev/project/v3 > but it doesn't work due to a bug in > https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/maven-scm-providers/maven-scm-provider-hg/src/main/java/org/apache/maven/scm/provider/hg/HgScmProvider.java > private HgUrlParserResult parseScmUrl( String scmSpecificUrl ) > line 104: if ( !url.startsWith( "file:///" ) && !url.startsWith( > "file://localhost/" ) ) > The fix might be the following (like in svn provider) > line 104: if ( !url.startsWith( "file://" ) && !url.startsWith( > "file://localhost/" ) ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343123#comment-343123 ] Jan Novotný commented on SCM-740: - Thanks for merging this into the trunk @Mark, I'll gladly get rid of our patched JAR in local Maven Repository. > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný >Assignee: Mark Struberg > Fix For: 1.10 > > Attachments: Wrong_base_directory_used1.patch > > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343122#comment-343122 ] Cem Koc commented on SCM-740: - @Mark, Is there any timeline for release v1.10? > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný >Assignee: Mark Struberg > Fix For: 1.10 > > Attachments: Wrong_base_directory_used1.patch > > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJARSIGNER-36) Use maven-shared-utils 0.6 and maven-jarsigner 1.3.2
[ https://jira.codehaus.org/browse/MJARSIGNER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit closed MJARSIGNER-36. - Resolution: Fixed Fix Version/s: 1.3.2 > Use maven-shared-utils 0.6 and maven-jarsigner 1.3.2 > > > Key: MJARSIGNER-36 > URL: https://jira.codehaus.org/browse/MJARSIGNER-36 > Project: Maven Jar Signer Plugin > Issue Type: Task >Affects Versions: 1.3.1 >Reporter: Tony Chemit >Assignee: Tony Chemit > Fix For: 1.3.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJARSIGNER-36) Use maven-shared-utils 0.6 and maven-jarsigner 1.3.2
[ https://jira.codehaus.org/browse/MJARSIGNER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343116#comment-343116 ] Tony Chemit commented on MJARSIGNER-36: --- Done in Done in [r1578838|http://svn.apache.org/r1578838] > Use maven-shared-utils 0.6 and maven-jarsigner 1.3.2 > > > Key: MJARSIGNER-36 > URL: https://jira.codehaus.org/browse/MJARSIGNER-36 > Project: Maven Jar Signer Plugin > Issue Type: Task >Affects Versions: 1.3.1 >Reporter: Tony Chemit >Assignee: Tony Chemit > Fix For: 1.3.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJARSIGNER-36) Use maven-shared-utils 0.6 and maven-jarsigner 1.3.2
[ https://jira.codehaus.org/browse/MJARSIGNER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit updated MJARSIGNER-36: -- Assignee: Tony Chemit > Use maven-shared-utils 0.6 and maven-jarsigner 1.3.2 > > > Key: MJARSIGNER-36 > URL: https://jira.codehaus.org/browse/MJARSIGNER-36 > Project: Maven Jar Signer Plugin > Issue Type: Task >Affects Versions: 1.3.1 >Reporter: Tony Chemit >Assignee: Tony Chemit > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-322) Use maven-shared-utils 0.6
[ https://jira.codehaus.org/browse/MSHARED-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Chemit closed MSHARED-322. --- Resolution: Fixed Fix Version/s: maven-jarsigner-1.3.2 Done in http://svn.apache.org/r1578834 > Use maven-shared-utils 0.6 > -- > > Key: MSHARED-322 > URL: https://jira.codehaus.org/browse/MSHARED-322 > Project: Maven Shared Components > Issue Type: Task > Components: maven-jarsigner >Affects Versions: maven-jarsigner-1.3.1 >Reporter: Tony Chemit >Assignee: Tony Chemit > Fix For: maven-jarsigner-1.3.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MANTRUN-183) Test scope resolution kills runtime dependencies
Michael Osipov created MANTRUN-183:
--
Summary: Test scope resolution kills runtime dependencies
Key: MANTRUN-183
URL: https://jira.codehaus.org/browse/MANTRUN-183
Project: Maven Antrun Plugin
Issue Type: Bug
Affects Versions: 1.7
Reporter: Michael Osipov
I am running {{antrun:run}} along with {{tomcat:deploy-only}} in one go. The
webapp to be uploaded contains runtime dependencies which are bundled with the
webapp and deployed to a remote server.
However, the test scope resolution of the antrun plugin
[removes|http://docs.codehaus.org/display/MAVENUSER/Dependency+Scopes] them
from the build list and the build fails. this applies to reactor dependencies.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-186) Create a rule for the reactor (ReactorModuleConvergence)
[
https://jira.codehaus.org/browse/MENFORCER-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343112#comment-343112
]
Samuel Langlois commented on MENFORCER-186:
---
Thank you for this new rule! I was looking for a nasty hack to do exactly
this...
Note that currently (r1578567), the {{}} that you pass to the
configuration is not displayed when the rule fails -- but maybe you didn't code
this behaviour so far.
> Create a rule for the reactor (ReactorModuleConvergence)
>
>
> Key: MENFORCER-186
> URL: https://jira.codehaus.org/browse/MENFORCER-186
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4
>
>
> It would be nice having a rule which checks the consitency of a multi-module
> build.
> Say having a build with modules like this:
> {code}
> +-- root (pom.xml)
> +--- m1 (pom.xml)
>+--- m11 (pom.xml)
>+--- m12 (pom.xml)
> +--- m2 (pom.xml)
>+--- m21 (pom.xml)
>+--- m21 (pom.xml)
> +--- m3 (pom.xml)
>+--- m31 (pom.xml)
>+--- m31 (pom.xml)
> +--- m4 (pom.xml)
> +--- m5 (pom.xml)
> {code}
> If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
> But what sometimes it happens that someone changes something and you will
> find things like the following:
> The module m21 (pom.xml) has a parent version of 1.1.0-SNAPSHOT instead of
> 1.2.0-SNAPSHOT which means maven will try to find this version in repository
> (you will get a warning during the build; But who reads warnings ;-))..
> Or other things having module interdependencies and it happens someone does
> something like this:
> In m4 a dependency is written like this:
> {code}
>
>TheGroup
>m21
>1.1.0-SNAPSHOT
>
> {code}
> which will usually build (except your SNAPSHOT's have been deleted before),
> but it is not correct. or better like this:
> {code}
>
>TheGroup
>m21
>1.1.0
>
> {code}
> This means it will be solved against a released version which usually is not
> the intention in such cases.
> So the rule should check if the groupId/artifactId belongs to the reactor and
> check the consistency of the version of the dependencies etc. Also the parent
> would be nice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-325) maven-filtering 1.2 throws MavenFilteringException: Mark invalid
[
https://jira.codehaus.org/browse/MSHARED-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikolaj Izdebski updated MSHARED-325:
-
Attachment: 0001-Add-unit-test-for-MSHARED-325.patch
Reproducer in a form of unit test
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid
>
>
> Key: MSHARED-325
> URL: https://jira.codehaus.org/browse/MSHARED-325
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.2
>Reporter: Mikolaj Izdebski
> Attachments: 0001-Add-unit-test-for-MSHARED-325.patch, payload
>
>
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid on some
> resource files, which filtering is successfull with version 1.1.
> An example payload is attached. I will attach a reproducer as a unit test
> too.
> {code}
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
> invalid
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:301)
> ... 21 more
> Caused by: java.io.IOException: Mark invalid
> at java.io.BufferedReader.reset(BufferedReader.java:505)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
> at
> org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
> at java.io.Reader.read(Reader.java:140)
> at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
> at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
> at
> org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
> ... 23 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-325) maven-filtering 1.2 throws MavenFilteringException: Mark invalid
Mikolaj Izdebski created MSHARED-325:
Summary: maven-filtering 1.2 throws MavenFilteringException: Mark
invalid
Key: MSHARED-325
URL: https://jira.codehaus.org/browse/MSHARED-325
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Mikolaj Izdebski
Attachments: payload
maven-filtering 1.2 throws MavenFilteringException: Mark invalid on some
resource files, which filtering is successfull with version 1.1.
An example payload is attached. I will attach a reproducer as a unit test too.
{code}
Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:301)
... 21 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:505)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
at java.io.Reader.read(Reader.java:140)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
... 23 more
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
