[jira] [Commented] (MRELEASE-1028) OddEven release policy does not support numeric qualifiers in versions
[
https://issues.apache.org/jira/browse/MRELEASE-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936807#comment-16936807
]
Robert Munteanu commented on MRELEASE-1028:
---
/CC [~simone.tripodi] - FYI
> OddEven release policy does not support numeric qualifiers in versions
> --
>
> Key: MRELEASE-1028
> URL: https://issues.apache.org/jira/browse/MRELEASE-1028
> Project: Maven Release Plugin
> Issue Type: Bug
>Reporter: Robert Munteanu
>Priority: Major
>
> We are using {{maven-release-oddeven-policy:2.5.3}} in our projects to
> automate the way our versioning process works.
> We sometimes use project versions which contain two versions, e.g. when
> tracking the version of an API specification or relevant external dependency.
> For instance, Foo Wrapper 1.1.0-1.0.5 is a bundle that wraps Foo version
> 1.0.5 and is itself at version 1.1.0 .
> Assuming a Foo version of 1.0.5, at development time, the bundle version
> would be 1.1.1-1.0.5-SNAPSHOT and at release time 1.1.2-1.0.5 .
> However, the odd/even release policy would propose a release version of
> 1.1.1-2.0.5 at release time. IIUC the change is not in line with how Maven
> defines versios ( 1.0.5 is just a qualifier ) and the release policy should
> be corrected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRELEASE-1028) OddEven release policy does not support numeric qualifiers in versions
[
https://issues.apache.org/jira/browse/MRELEASE-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated MRELEASE-1028:
--
Summary: OddEven release policy does not support numeric qualifiers in
versions (was: OddEven release policy does not support qualifiers in versions)
> OddEven release policy does not support numeric qualifiers in versions
> --
>
> Key: MRELEASE-1028
> URL: https://issues.apache.org/jira/browse/MRELEASE-1028
> Project: Maven Release Plugin
> Issue Type: Bug
>Reporter: Robert Munteanu
>Priority: Major
>
> We are using {{maven-release-oddeven-policy:2.5.3}} in our projects to
> automate the way our versioning process works.
> We sometimes use project versions which contain two versions, e.g. when
> tracking the version of an API specification or relevant external dependency.
> For instance, Foo Wrapper 1.1.0-1.0.5 is a bundle that wraps Foo version
> 1.0.5 and is itself at version 1.1.0 .
> Assuming a Foo version of 1.0.5, at development time, the bundle version
> would be 1.1.1-1.0.5-SNAPSHOT and at release time 1.1.2-1.0.5 .
> However, the odd/even release policy would propose a release version of
> 1.1.1-2.0.5 at release time. IIUC the change is not in line with how Maven
> defines versios ( 1.0.5 is just a qualifier ) and the release policy should
> be corrected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MRELEASE-1028) OddEven release policy does not support qualifiers in versions
Robert Munteanu created MRELEASE-1028:
-
Summary: OddEven release policy does not support qualifiers in
versions
Key: MRELEASE-1028
URL: https://issues.apache.org/jira/browse/MRELEASE-1028
Project: Maven Release Plugin
Issue Type: Bug
Reporter: Robert Munteanu
We are using {{maven-release-oddeven-policy:2.5.3}} in our projects to automate
the way our versioning process works.
We sometimes use project versions which contain two versions, e.g. when
tracking the version of an API specification or relevant external dependency.
For instance, Foo Wrapper 1.1.0-1.0.5 is a bundle that wraps Foo version 1.0.5
and is itself at version 1.1.0 .
Assuming a Foo version of 1.0.5, at development time, the bundle version would
be 1.1.1-1.0.5-SNAPSHOT and at release time 1.1.2-1.0.5 .
However, the odd/even release policy would propose a release version of
1.1.1-2.0.5 at release time. IIUC the change is not in line with how Maven
defines versios ( 1.0.5 is just a qualifier ) and the release policy should be
corrected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249224#comment-16249224 ] Robert Munteanu commented on MJAR-193: -- So would the extension point be for instance an interface declared in the maven-jar-plugin and then implemented by other plugins? I gues Plexus can be used for the plumbing > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249224#comment-16249224 ] Robert Munteanu edited comment on MJAR-193 at 11/13/17 8:16 AM: So would the extension point be for instance an interface declared in the maven-jar-plugin and then implemented by other plugins? I guess Plexus can be used for the plumbing _edit_: typo was (Author: rombert): So would the extension point be for instance an interface declared in the maven-jar-plugin and then implemented by other plugins? I gues Plexus can be used for the plumbing > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247599#comment-16247599 ] Robert Munteanu commented on MJAR-193: -- [~rfscholte] - what kind of extension point were you considering? I am somewhat familiar with writing Maven plugins but never considered extension points. > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MANTRUN-200) Scriptdef tasks fail to load when running on Java9
[
https://issues.apache.org/jira/browse/MANTRUN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16136516#comment-16136516
]
Robert Munteanu commented on MANTRUN-200:
-
Maybe someone from the Maven core team can comment? [~rfscholte]?
> Scriptdef tasks fail to load when running on Java9
> --
>
> Key: MANTRUN-200
> URL: https://issues.apache.org/jira/browse/MANTRUN-200
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Dan Berindei
>
> I have a Maven project using maven-antrun-plugin:
> {code}
>
>
>4.0.0
>my-test-app
>my-test-group
>1.0-SNAPSHOT
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
>
>
> compile
> compile
>
>
>
>
>
>
>
>
> run
>
>
>
>
>
>
>
> {code}
> The Ant build file uses a script:
> {code}
>
>
>
>
>
>
>
>
>
> {code}
> On Java 8 it works, but on Java 9 (9-ea+162) it can't find the script engine:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (compile) on
> project my-test-app: An Ant BuildException has occured: The following error
> occurred while executing this line:
> /home/dan/scriptdef-test/build.xml:10: Unable to create javax script engine
> for javascript
> around Ant part .. @ 4:47 in
> /home/dan/scriptdef-test/target/antrun/build-main.xml
> ...
> Caused by: /home/dan/scriptdef-test/build.xml:10: Unable to create javax
> script engine for javascript
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:84)
> at
> org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDef.executeScript(ScriptDef.java:350)
> at
> org.apache.tools.ant.taskdefs.optional.script.ScriptDefBase.execute(ScriptDefBase.java:50)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:547)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> ... 34 more
> {noformat}
> I have attached a debugger and I saw that the {{ScriptEngineManager}} used by
> {{JavaxScriptRunner}} doesn't have any script engines, because the service
> loader it uses doesn't find any {{ScriptEngineFactory}} implementations. I
> have tried {{\--add-modules jdk.scripting.nashorn}} and {{\--add-opens
> jdk.scripting.nashorn/jdk.nashorn.api.scripting=ALL-UNNAMED}}, but neither
> helped.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARCHETYPE-519) archetype:generate with specified remote archetypeCatalog falls back to internal catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15885514#comment-15885514
]
Robert Munteanu commented on ARCHETYPE-519:
---
+1, our users found out the hard way about this change, and I too will have to
explicitly reference 2.4 in the documentation. IMHO it's editing settings.xml
"just" for an archetype is more trouble than it's worth, and users would be
turned away from that.
> archetype:generate with specified remote archetypeCatalog falls back to
> internal catalog
>
>
> Key: ARCHETYPE-519
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-519
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.0.0
> Environment: Mac OS X 10.11.6, Apache Maven 3.2.3
>Reporter: Philip Mundt
>Assignee: Robert Scholte
> Fix For: 3.0.1
>
>
> We were surprised to find out that our archetype was "suddenly" not working
> anymore. It turns out it was the release of
> {{org.apache.maven.plugins:maven-archetype-plugin:3.0.0}} from 12/Feb/17 that
> was the culprit.
> When running:
> {{mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate
> -DarchetypeCatalog=}} we end up with the
> plugin falling back to the internal catalog:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] >>> maven-archetype-plugin:3.0.0:generate (default-cli) >
> generate-sources @ standalone-pom >>>
> [INFO]
> [INFO] <<< maven-archetype-plugin:3.0.0:generate (default-cli) <
> generate-sources @ standalone-pom <<<
> [INFO]
> [INFO] --- maven-archetype-plugin:3.0.0:generate (default-cli) @
> standalone-pom ---
> [INFO] Generating project in Interactive mode
> [INFO] No catalog defined. Using internal catalog
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: internal -> org.apache.maven.archetypes:maven-archetype-archetype (An
> archetype which contains a sample archetype.)
> 2: internal -> org.apache.maven.archetypes:maven-archetype-j2ee-simple (An
> archetype which contains a simplifed sample J2EE application.)
> 3: internal -> org.apache.maven.archetypes:maven-archetype-plugin (An
> archetype which contains a sample Maven plugin.)
> 4: internal -> org.apache.maven.archetypes:maven-archetype-plugin-site (An
> archetype which contains a sample Maven plugin site.
> This archetype can be layered upon an existing Maven plugin project.)
> 5: internal -> org.apache.maven.archetypes:maven-archetype-portlet (An
> archetype which contains a sample JSR-268 Portlet.)
> 6: internal -> org.apache.maven.archetypes:maven-archetype-profiles ()
> 7: internal -> org.apache.maven.archetypes:maven-archetype-quickstart (An
> archetype which contains a sample Maven project.)
> 8: internal -> org.apache.maven.archetypes:maven-archetype-site (An archetype
> which contains a sample Maven site which demonstrates
> some of the supported document types like APT, XDoc, and FML and
> demonstrates how
> to i18n your site. This archetype can be layered upon an existing Maven
> project.)
> 9: internal -> org.apache.maven.archetypes:maven-archetype-site-simple (An
> archetype which contains a sample Maven site.)
> 10: internal -> org.apache.maven.archetypes:maven-archetype-webapp (An
> archetype which contains a sample Maven Webapp project.)
> Choose a number or apply filter (format: [groupId:]artifactId, case sensitive
> contains):
> {code}
> Version 2.4 works as expected (the archetype catalog exists under given URL
> and can be downloaded).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[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-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=332845#comment-332845
]
Robert Munteanu commented on MRELEASE-431:
--
[~rfscholte] - thanks for the info, I just wanted to know if you'd like any
changes made in the short term. I fully agree that - being published API - we
need to get it right the first time.
{quote} Another thing on my mind: should the API support methods to make it a
major, minor or bugversion increase, or leave that up to the
implementation{quote}
I guess we could, but maybe as part of another utility class, to keep the
VersionPolicyManager API clean. Not sure if that needs to be API though, or we
could simply provide it as a convenience for implementors.
> 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
>
>
> 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=332400#comment-332400
]
Robert Munteanu commented on MRELEASE-431:
--
[~rscholte] - I'm not sure what you mean. I was able to test the newly-supplied
odd/even release scheme by:
1. Installing my local copy of the plugin
2. Adding the following to the pom file
{code}
org.apache.maven.plugins
maven-release-plugin
{code}
3. Running {{mvn
org.apache.maven.plugins:maven-release-plugin:2.4.2-SNAPSHOT:prepare}}
I've used the expanded g:a:v:goal syntax to avoid declaring snapshot
dependencies on the pom.xml . And for me it works as expected, and matches your
comment #5 about using Plexus configuration.
> 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
>
>
> 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=330241#comment-330241 ] Robert Munteanu edited comment on MRELEASE-431 at 8/7/13 9:13 AM: -- [~rfscholte] - I _think_ I finally understood what you aimed to get with Plexus configuration. Please see the [^MRELEASE-431-v2.patch], which configures the versionPolicyManager as you asked. You can also see the [diff on github|https://github.com/rombert/release/compare/6de575dd76224c690bfd88375eac88f49ba6d319...HEAD] Let me know if there are any changes you would like applied, as I'm interested in getting this in a release. was (Author: rombert): [~rfscholte] - I _think_ I finally understood what you aimed to get with Plexus configuration. Please see the [^MRELEASE-431-v2.patch], which configures the versionPolicyManager as you asked. You can also see the[diff on github|https://github.com/rombert/release/compare/6de575dd76224c690bfd88375eac88f49ba6d319...HEAD] Let me know if there are any changes you would like applied, as I'm interested in getting this in a release. > 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 > > > 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:all-tabpanel ] Robert Munteanu updated MRELEASE-431: - Attachment: MRELEASE-431-v2.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 > > > 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=330241#comment-330241 ] Robert Munteanu commented on MRELEASE-431: -- [~rfscholte] - I _think_ I finally understood what you aimed to get with Plexus configuration. Please see the [^MRELEASE-431-v2.patch], which configures the versionPolicyManager as you asked. You can also see the[diff on github|https://github.com/rombert/release/compare/6de575dd76224c690bfd88375eac88f49ba6d319...HEAD] Let me know if there are any changes you would like applied, as I'm interested in getting this in a release. > 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 > > > 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:all-tabpanel ] Robert Munteanu updated MRELEASE-431: - Attachment: MRELEASE-431.patch I've updated the code to make the VersionPolicyManager a plexus component, and it's now injected by plexus into the MapVersionsPhase. However, I don't know where I can override the implementation using Plexus configuration as you suggested, so any hints are appreciated. Besides the updated [^MRELEASE-431.patch], you can also view the [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 > > > 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=326956#comment-326956 ] Robert Munteanu commented on MRELEASE-431: -- Right, so I'll create a VersionPolicyManager interface, and I can look it up based on the configured versionPolicy parameter. What I'm not sure is how to actually provide and look up implementations for this interface, since I'm not familiar with Maven component wiring. Where can I find the docs or a working example? And for now I can add a release-api project to the release reactor, and you can decide whether to move it to a shared component later, since it would be more difficult for me, not being a Maven committer. WDYT? > Configuration of policy for calculating next (release) version > -- > > Key: MRELEASE-431 > URL: https://jira.codehaus.org/browse/MRELEASE-431 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-8 >Reporter: Carsten Ziegeler > Attachments: > 0001-MRELEASE-431-Configuration-of-policy-for-calculating.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=326938#comment-326938 ] Robert Munteanu commented on MRELEASE-431: -- I've attached a patch which adds a 'versionPolicy' property to the plugin. Possible values are 'default' - which is what the plugin does today - and 'odd-even', which ensures that snapshot dependencies are always odd and release versions are always even. You can also review the [commit on github|https://github.com/rombert/release/commit/35e42901868d5c18289e6687bbecdd78cddbf03e] as well. I tried to keep changes minimal and self-contained and also added tests as well as I could. I'm open to iterating on this so please let me know what you think. Thanks! Robert > Configuration of policy for calculating next (release) version > -- > > Key: MRELEASE-431 > URL: https://jira.codehaus.org/browse/MRELEASE-431 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-8 >Reporter: Carsten Ziegeler > Attachments: > 0001-MRELEASE-431-Configuration-of-policy-for-calculating.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:all-tabpanel ] Robert Munteanu updated MRELEASE-431: - Attachment: 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch > Configuration of policy for calculating next (release) version > -- > > Key: MRELEASE-431 > URL: https://jira.codehaus.org/browse/MRELEASE-431 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 2.0-beta-8 >Reporter: Carsten Ziegeler > Attachments: > 0001-MRELEASE-431-Configuration-of-policy-for-calculating.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] (MNG-1911) Building plugins with extensions in a reactor fails
[ https://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297175#comment-297175 ] Robert Munteanu commented on MNG-1911: -- This also affects the Apache Sling build. > Building plugins with extensions in a reactor fails > --- > > Key: MNG-1911 > URL: https://jira.codehaus.org/browse/MNG-1911 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.1 >Reporter: Guillaume Nodet >Priority: Critical > Fix For: 3.1 > > Attachments: MNG-1911.zip > > > I have the following in my main pom > > > > > org.apache.servicemix.plugins > maven2-jbi-plugin > 1.0-SNAPSHOT > true > > > > > If i try to add it to the modules, the first time, maven complains that it > can not download the plugin. > If i remove the tag, all works, but i need it :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4633) Make weave mode work reliably
[
http://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229804#action_229804
]
Robert Munteanu commented on MNG-4633:
--
The plugin is the maven-compiler-plugin , and it's bound to two executions :
once in generate-sources, another in default-compiler. And yes, module B
depends on the classes from module A. It's worth mentioning that all execution
so far was done on a single thread, judging from the thread names.
Also, I get some warnings regarding n...@threadsafe plugins. Should I worry
about these:
{code}
[WARNING] The following plugins are not marked @threadSafe in ...:
[WARNING] org.apache.maven.plugins:maven-surefire-plugin:2.5
[WARNING] org.codehaus.mojo:build-helper-maven-plugin:1.5
[WARNING] org.apache.maven.plugins:maven-enforcer-plugin:1.0-beta-1
{code}
Since I'm running a SNAPSHOT build I need to skip the enforcer plugin. I've
also tried with the tests skipped, but that made no difference.
> Make weave mode work reliably
> -
>
> Key: MNG-4633
> URL: http://jira.codehaus.org/browse/MNG-4633
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.0-beta-1
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 3.0-beta-2
>
>
> m3 trunk currently contains two different concurrent-build implementations;
> parallel and weave. The main target for m3 is for production quality
> "parallel" to be ready; there are numerous plugins that will need to adjust
> to this functionality.
> Alongside this activity weave mode will also be fine-tuned and evaluated; due
> to the generally tighter concurrency in this model, weave mode is more likely
> to reveal concurrency related issues in both maven, plugins, libraries and
> the jdk.
> This task is used to collect all commits related to making weave mode work
> reliably. The final evaluation of weave mode will be taken at a later stage.
> In the event that Weave mode is to be abandoned, the class
> LifecycleWeaveBuilder contains instructions on how/what can be removed from
> m3 core.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4633) Make weave mode work reliably
[ http://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229693#action_229693 ] Robert Munteanu commented on MNG-4633: -- I have performed a test, and it seems that module A now runs its default-compile phase, but the classes are still not visible to B. A goes all the way to default-jar, but then B's generate-sources - which is actually a maven-compiler-plugin goal - is invoked, the classes are not found. > Make weave mode work reliably > - > > Key: MNG-4633 > URL: http://jira.codehaus.org/browse/MNG-4633 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.0-beta-1 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 3.0-beta-2 > > > m3 trunk currently contains two different concurrent-build implementations; > parallel and weave. The main target for m3 is for production quality > "parallel" to be ready; there are numerous plugins that will need to adjust > to this functionality. > Alongside this activity weave mode will also be fine-tuned and evaluated; due > to the generally tighter concurrency in this model, weave mode is more likely > to reveal concurrency related issues in both maven, plugins, libraries and > the jdk. > This task is used to collect all commits related to making weave mode work > reliably. The final evaluation of weave mode will be taken at a later stage. > In the event that Weave mode is to be abandoned, the class > LifecycleWeaveBuilder contains instructions on how/what can be removed from > m3 core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4633) Make weave mode work reliably
[ http://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229192#action_229192 ] Robert Munteanu commented on MNG-4633: -- Is this the correct place to report bugs with Weave mode? I have found a potential bug, but am not sure where this should be reported. Briefly, I have two modules which depend on each other ( A,B ) , with the B module's generate-sources phase depending on the output of the A module's compile phase. Apparently weave mode does not see things this way, and I get compiler errors due to classes not found. > Make weave mode work reliably > - > > Key: MNG-4633 > URL: http://jira.codehaus.org/browse/MNG-4633 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.0-beta-1 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 3.0-beta-2 > > > m3 trunk currently contains two different concurrent-build implementations; > parallel and weave. The main target for m3 is for production quality > "parallel" to be ready; there are numerous plugins that will need to adjust > to this functionality. > Alongside this activity weave mode will also be fine-tuned and evaluated; due > to the generally tighter concurrency in this model, weave mode is more likely > to reveal concurrency related issues in both maven, plugins, libraries and > the jdk. > This task is used to collect all commits related to making weave mode work > reliably. The final evaluation of weave mode will be taken at a later stage. > In the event that Weave mode is to be abandoned, the class > LifecycleWeaveBuilder contains instructions on how/what can be removed from > m3 core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTTASKS-174) Mirror declaration replaces url from distributionManagement
Mirror declaration replaces url from distributionManagement
---
Key: MANTTASKS-174
URL: http://jira.codehaus.org/browse/MANTTASKS-174
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: deploy task
Affects Versions: 2.1.0
Environment: Ant 1.7.1, Maven ant tasks 2.1.0
Reporter: Robert Munteanu
Given a ~/.m2/settings.xml file containing a mirror element
{code}
nexus
external:*
https://xxx.com/nexus/content/groups/public
{code}
a pom.xml file with a distributionManagement section
{code}
sonatype-nexus-snapshots
Sonatype Nexus Snapshots
http://oss.sonatype.org/content/repositories/snapshots
{code}
and a build.xml file with the following deploy task:
{code}
{code}
When running ant deploy the deployment is done on xxx.com instead of
oss.sonatype.org . Removing the mirror from the settings file solves the
problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2717) Please upload gin 1.0.0.
Please upload gin 1.0.0. Key: MAVENUPLOAD-2717 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2717 Project: Maven Upload Requests Issue Type: Wish Reporter: Robert Munteanu Please upload the attached repository bundle for Gin. Although I am not a developer, this upload is sanctioned by one of the developers ( http://code.google.com/p/google-gin/issues/detail?id=45#c12 ). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
