[jira] [Created] (MNG-6345) Support profile activation via script.
Andrei Pozolotin created MNG-6345: - Summary: Support profile activation via script. Key: MNG-6345 URL: https://issues.apache.org/jira/browse/MNG-6345 Project: Maven Issue Type: New Feature Components: Bootstrap & Build Affects Versions: 3.5.2 Reporter: Andrei Pozolotin Please consider introduction of new profile activation method: "script". Here is working prototype which adds required functionality via PropertyActivator: [https://github.com/random-maven/profile-activator-extension] in the final form, this feature usage will look like:javascript print("hello-maven"); return true;Suggested minimal supported script types: * Groovy * JavaScript * MVEL Script -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-3328) Allow multiple profile activation properties.
[
https://issues.apache.org/jira/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332530#comment-16332530
]
Andrei Pozolotin commented on MNG-3328:
---
FYI: [https://github.com/random-maven/profile-activator-extension] resolves the
issue
> Allow multiple profile activation properties.
> -
>
> Key: MNG-3328
> URL: https://issues.apache.org/jira/browse/MNG-3328
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.8
>Reporter: Paul Gier
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> The pom model should be changed to allow multiple properties to activate a
> profile. So the profile activation section could look something like this:
> {code:xml}
>
>
> some-value
> another-value
>
>
> {code}
> This would provide more flexibility in profile activation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5408) Explicit profile activation in pom.xml
[
https://issues.apache.org/jira/browse/MNG-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332527#comment-16332527
]
Andrei Pozolotin commented on MNG-5408:
---
FYI: [https://github.com/random-maven/profile-activator-extension] resolves the
issue
> Explicit profile activation in pom.xml
> --
>
> Key: MNG-5408
> URL: https://issues.apache.org/jira/browse/MNG-5408
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.0.4
>Reporter: Paul Lowry
>Priority: Major
>
> +Background:+
> Organisations should be able to define complex maven tasks, each involving
> multiple plugin executions, in a way that is standardised for use in all
> projects.
> The obvious solution would seem to be profiles:
> * They allow us to define maven project configuration and multiple plugin
> executions
> * They can be enabled/disabled, and they are not mutually exclusive, so we
> can use them to run execution A or execution B of the same plugin, or A and
> then B, or any other sequence (note: this sort of control is not available in
> pluginManagement)
> For example, consider an organisation where some project teams do integration
> testing of war artifacts by running them in Jetty, whereas others use Tomcat.
> Both scenarios require several plugins to run, and though the process is
> similar it is not the same (for our example, let's assume that Jetty requires
> a test context file, and Tomcat projects have a different naming scheme for
> their test classes).
> Using profiles in a root pom, which is the parent for all projects in the
> organisation, we can make the process for running a war in Jetty/Tomcat quite
> simple, and more importantly quite consistent:
> {code:xml|title=root.pom.xml}
>
>
>
>
> runJetty
>
>
>
> org.apache.maven.plugins
> maven-resources-plugin
>
>
> runJetty.prep
> pre-integration-test
>
> copy-resources
>
>
>
>
>
> \${project.build.testOutputDirectory}/jetty
> true
>
>
>
> \${project.build.directory}/\${project.build.finalName}
>
>
>
>
>
> org.mortbay.jetty
> jetty-maven-plugin
>
>
> runJetty.start
> pre-integration-test
>
>
>
> runJetty.stop
> post-integration-test
>
>
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
>
>
> runJetty.test
> integration-test
>
> integration-test
> verify
>
>
>
>
>
>
>
>
>
> runTomcat
>
>
>
> org.apache.tomcat.maven
> tomcat6-maven-plugin
>
>
> runTomcat.start
> pre-integration-test
>
>
>
>
>
> org.apache.maven.plugins
> maven-failsafe-plugin
>
>
> runTomcat.test
> integration-test
>
>
[jira] [Comment Edited] (MPLUGIN-247) Allow getting mojo/parameter description/since/deprecated from annotations
[
https://issues.apache.org/jira/browse/MPLUGIN-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16289627#comment-16289627
]
Andrei Pozolotin edited comment on MPLUGIN-247 at 12/14/17 2:20 AM:
For those interested: resolved with this hack:
https://github.com/random-maven/maven-plugin-tools-annotations
was (Author: andrei.pozolotin):
For those interested: resolved with this hack:
https://github.com/random-maven/maven-plugin-tools-java
> Allow getting mojo/parameter description/since/deprecated from annotations
> --
>
> Key: MPLUGIN-247
> URL: https://issues.apache.org/jira/browse/MPLUGIN-247
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: maven-plugin-annotations
>Affects Versions: 3.2
>Reporter: Alex Hvostov
>Priority: Minor
> Attachments: extra-annotations.diff
>
>
> The attached patch adds annotations {{@Description}}, {{@Since}}, and
> {{@DeprecatedBecause}}, which can be used instead of Javadoc comments for
> describing a Mojo and its parameters.
> My use-case for this feature is writing Maven plugins in Scala. This language
> supports annotations, but a Java parser will obviously not be able to extract
> description/since/deprecated information from Scala source files. (There is
> another {{plugin-tools}} implementation specifically for writing Scala
> plugins, which has its own set of annotations, but it is buggy, incomplete,
> and not under active development.)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MPLUGIN-247) Allow getting mojo/parameter description/since/deprecated from annotations
[
https://issues.apache.org/jira/browse/MPLUGIN-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16289627#comment-16289627
]
Andrei Pozolotin commented on MPLUGIN-247:
--
For those interested: resolved with this hack:
https://github.com/random-maven/maven-plugin-tools-java
> Allow getting mojo/parameter description/since/deprecated from annotations
> --
>
> Key: MPLUGIN-247
> URL: https://issues.apache.org/jira/browse/MPLUGIN-247
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: maven-plugin-annotations
>Affects Versions: 3.2
>Reporter: Alex Hvostov
>Priority: Minor
> Attachments: extra-annotations.diff
>
>
> The attached patch adds annotations {{@Description}}, {{@Since}}, and
> {{@DeprecatedBecause}}, which can be used instead of Javadoc comments for
> describing a Mojo and its parameters.
> My use-case for this feature is writing Maven plugins in Scala. This language
> supports annotations, but a Java parser will obviously not be able to extract
> description/since/deprecated information from Scala source files. (There is
> another {{plugin-tools}} implementation specifically for writing Scala
> plugins, which has its own set of annotations, but it is buggy, incomplete,
> and not under active development.)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MPLUGIN-247) Allow getting mojo/parameter description/since/deprecated from annotations
[
https://issues.apache.org/jira/browse/MPLUGIN-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16277145#comment-16277145
]
Andrei Pozolotin commented on MPLUGIN-247:
--
There are multitude of ways, from writing custom extractor with scala-meta to
adding annotation/description.
The annotation/description approach seems minimal-effort to me. Plus, it will
work in "any other java" context.
Am I wrong? What would you recommend? Will you accept a patch for
annotation/description support in java-extractor?
> Allow getting mojo/parameter description/since/deprecated from annotations
> --
>
> Key: MPLUGIN-247
> URL: https://issues.apache.org/jira/browse/MPLUGIN-247
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: maven-plugin-annotations
>Affects Versions: 3.2
>Reporter: Alex Hvostov
>Priority: Minor
> Attachments: extra-annotations.diff
>
>
> The attached patch adds annotations {{@Description}}, {{@Since}}, and
> {{@DeprecatedBecause}}, which can be used instead of Javadoc comments for
> describing a Mojo and its parameters.
> My use-case for this feature is writing Maven plugins in Scala. This language
> supports annotations, but a Java parser will obviously not be able to extract
> description/since/deprecated information from Scala source files. (There is
> another {{plugin-tools}} implementation specifically for writing Scala
> plugins, which has its own set of annotations, but it is buggy, incomplete,
> and not under active development.)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MPLUGIN-247) Allow getting mojo/parameter description/since/deprecated from annotations
[
https://issues.apache.org/jira/browse/MPLUGIN-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275927#comment-16275927
]
Andrei Pozolotin commented on MPLUGIN-247:
--
[~rfscholte] Robert Scholte: please explain if there is a chance for this ever
be implemented?
> Allow getting mojo/parameter description/since/deprecated from annotations
> --
>
> Key: MPLUGIN-247
> URL: https://issues.apache.org/jira/browse/MPLUGIN-247
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: maven-plugin-annotations
>Affects Versions: 3.2
>Reporter: Alex Hvostov
>Priority: Minor
> Attachments: extra-annotations.diff
>
>
> The attached patch adds annotations {{@Description}}, {{@Since}}, and
> {{@DeprecatedBecause}}, which can be used instead of Javadoc comments for
> describing a Mojo and its parameters.
> My use-case for this feature is writing Maven plugins in Scala. This language
> supports annotations, but a Java parser will obviously not be able to extract
> description/since/deprecated information from Scala source files. (There is
> another {{plugin-tools}} implementation specifically for writing Scala
> plugins, which has its own set of annotations, but it is buggy, incomplete,
> and not under active development.)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MPLUGIN-329) support for "description" in mojo annotations / extractors for plugin.xml
[ https://issues.apache.org/jira/browse/MPLUGIN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Pozolotin updated MPLUGIN-329: - Description: 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html 2) this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: /** * Enable to perform deployment. */ @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement was: 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html 2) this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: /** * Enable to perform deployment. */ @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement > support for "description" in mojo annotations / extractors for plugin.xml > - > > Key: MPLUGIN-329 > URL: https://issues.apache.org/jira/browse/MPLUGIN-329 > Project: Maven Plugin Tools > Issue Type: Bug > Components: maven-plugin-annotations, maven-plugin-tools-java >Affects Versions: 3.5 > Environment: java 8 >Reporter: Andrei Pozolotin > Labels: easyfix, features > > 1) currently, plugin.xml descriptor is generated by extractors > which look basically in 2 places: > a) annotations > b) javadoc > in cases when plugin is written in "other java": scala, groovy, etc i.e. : > https://github.com/random-maven/bintray-maven-plugin > a) annotations work just fine > b) but javadoc descriptions are lost > https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html > 2) this request is to add extra field *description* to all mojo annotations > https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations > so for example: > /** > * Enable to perform deployment. > */ > @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) > becomes: > @Parameter( > description = "Enable to perform deployment.", > property = "bintray.performDeploy", >defaultValue = "true" >) > it seems this feature requires minor effort, yet can result in major > improvement -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MPLUGIN-329) support for "description" in mojo annotations / extractors for plugin.xml
[
https://issues.apache.org/jira/browse/MPLUGIN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Pozolotin updated MPLUGIN-329:
-
Description:
1) currently, plugin.xml descriptor is generated by extractors
which look basically in 2 places:
a) annotations
b) javadoc
in cases when plugin is written in "other java": scala, groovy, etc i.e. :
https://github.com/random-maven/bintray-maven-plugin
a) annotations work just fine
b) but javadoc descriptions are lost
https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html
2) this request is to add extra field *description* to all mojo annotations
https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations
so for example:
/**
** Enable to perform deployment.
**/
@Parameter( property = "bintray.performDeploy", defaultValue = "true" )
becomes:
@Parameter(
description = "Enable to perform deployment.",
property = "bintray.performDeploy",
defaultValue = "true"
)
it seems this feature requires minor effort, yet can result in major improvement
was:
1) currently, plugin.xml descriptor is generated by extractors
which look basically in 2 places:
a) annotations
b) javadoc
in cases when plugin is written in "other java": scala, groovy, etc i.e. :
https://github.com/random-maven/bintray-maven-plugin
a) annotations work just fine
b) but javadoc descriptions are lost
https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html
2) this request is to add extra field *description* to all mojo annotations
https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations
so for example:
{{/**
* Enable to perform deployment.
*/
@Parameter( property = "bintray.performDeploy", defaultValue = "true" )}}
becomes:
{{@Parameter(
description = "Enable to perform deployment.",
property = "bintray.performDeploy",
defaultValue = "true"
)}}
it seems this feature requires minor effort, yet can result in major improvement
> support for "description" in mojo annotations / extractors for plugin.xml
> -
>
> Key: MPLUGIN-329
> URL: https://issues.apache.org/jira/browse/MPLUGIN-329
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-annotations, maven-plugin-tools-java
>Affects Versions: 3.5
> Environment: java 8
>Reporter: Andrei Pozolotin
> Labels: easyfix, features
>
> 1) currently, plugin.xml descriptor is generated by extractors
> which look basically in 2 places:
> a) annotations
> b) javadoc
> in cases when plugin is written in "other java": scala, groovy, etc i.e. :
> https://github.com/random-maven/bintray-maven-plugin
> a) annotations work just fine
> b) but javadoc descriptions are lost
> https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html
> 2) this request is to add extra field *description* to all mojo annotations
> https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations
> so for example:
> /**
> ** Enable to perform deployment.
> **/
> @Parameter( property = "bintray.performDeploy", defaultValue = "true" )
> becomes:
> @Parameter(
> description = "Enable to perform deployment.",
> property = "bintray.performDeploy",
> defaultValue = "true"
> )
> it seems this feature requires minor effort, yet can result in major
> improvement
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MPLUGIN-329) support for "description" in mojo annotations / extractors for plugin.xml
[ https://issues.apache.org/jira/browse/MPLUGIN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Pozolotin updated MPLUGIN-329: - Description: 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html 2) this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: /** * Enable to perform deployment. */ @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement was: 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html 2) this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: /** ** Enable to perform deployment. **/ @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement > support for "description" in mojo annotations / extractors for plugin.xml > - > > Key: MPLUGIN-329 > URL: https://issues.apache.org/jira/browse/MPLUGIN-329 > Project: Maven Plugin Tools > Issue Type: Bug > Components: maven-plugin-annotations, maven-plugin-tools-java >Affects Versions: 3.5 > Environment: java 8 >Reporter: Andrei Pozolotin > Labels: easyfix, features > > 1) currently, plugin.xml descriptor is generated by extractors > which look basically in 2 places: > a) annotations > b) javadoc > in cases when plugin is written in "other java": scala, groovy, etc i.e. : > https://github.com/random-maven/bintray-maven-plugin > a) annotations work just fine > b) but javadoc descriptions are lost > https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html > 2) this request is to add extra field *description* to all mojo annotations > https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations > so for example: >/** >* Enable to perform deployment. >*/ >@Parameter( property = "bintray.performDeploy", defaultValue = "true" ) > becomes: >@Parameter( >description = "Enable to perform deployment.", >property = "bintray.performDeploy", >defaultValue = "true" >) > it seems this feature requires minor effort, yet can result in major > improvement -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MPLUGIN-329) support for "description" in mojo annotations / extractors for plugin.xml
[
https://issues.apache.org/jira/browse/MPLUGIN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Pozolotin updated MPLUGIN-329:
-
Description:
1) currently, plugin.xml descriptor is generated by extractors
which look basically in 2 places:
a) annotations
b) javadoc
in cases when plugin is written in "other java": scala, groovy, etc i.e. :
https://github.com/random-maven/bintray-maven-plugin
a) annotations work just fine
b) but javadoc descriptions are lost
https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html
2) this request is to add extra field *description* to all mojo annotations
https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations
so for example:
{{/**
* Enable to perform deployment.
*/
@Parameter( property = "bintray.performDeploy", defaultValue = "true" )}}
becomes:
{{@Parameter(
description = "Enable to perform deployment.",
property = "bintray.performDeploy",
defaultValue = "true"
)}}
it seems this feature requires minor effort, yet can result in major improvement
was:
1) currently, plugin.xml descriptor is generated by extractors
which look basically in 2 places:
a) annotations
b) javadoc
in cases when plugin is written in "other java": scala, groovy, etc i.e. :
https://github.com/random-maven/bintray-maven-plugin
a) annotations work just fine
b) but javadoc descriptions are lost
https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html
2) this request is to add extra field *description* to all mojo annotations
https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations
so for example:
/**
* Enable to perform deployment.
*/
@Parameter( property = "bintray.performDeploy", defaultValue = "true" )
becomes:
@Parameter(
description = "Enable to perform deployment.",
property = "bintray.performDeploy",
defaultValue = "true"
)
it seems this feature requires minor effort, yet can result in major improvement
> support for "description" in mojo annotations / extractors for plugin.xml
> -
>
> Key: MPLUGIN-329
> URL: https://issues.apache.org/jira/browse/MPLUGIN-329
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-annotations, maven-plugin-tools-java
>Affects Versions: 3.5
> Environment: java 8
>Reporter: Andrei Pozolotin
> Labels: easyfix, features
>
> 1) currently, plugin.xml descriptor is generated by extractors
> which look basically in 2 places:
> a) annotations
> b) javadoc
> in cases when plugin is written in "other java": scala, groovy, etc i.e. :
> https://github.com/random-maven/bintray-maven-plugin
> a) annotations work just fine
> b) but javadoc descriptions are lost
> https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html
> 2) this request is to add extra field *description* to all mojo annotations
> https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations
> so for example:
> {{/**
> * Enable to perform deployment.
> */
> @Parameter( property = "bintray.performDeploy", defaultValue = "true" )}}
> becomes:
> {{@Parameter(
> description = "Enable to perform deployment.",
> property = "bintray.performDeploy",
> defaultValue = "true"
> )}}
> it seems this feature requires minor effort, yet can result in major
> improvement
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MPLUGIN-329) support for "description" in mojo annotations / extractors for plugin.xml
[ https://issues.apache.org/jira/browse/MPLUGIN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Pozolotin updated MPLUGIN-329: - Description: 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html 2) this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: /** * Enable to perform deployment. */ @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement was: 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html 2) this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement > support for "description" in mojo annotations / extractors for plugin.xml > - > > Key: MPLUGIN-329 > URL: https://issues.apache.org/jira/browse/MPLUGIN-329 > Project: Maven Plugin Tools > Issue Type: Bug > Components: maven-plugin-annotations, maven-plugin-tools-java >Affects Versions: 3.5 > Environment: java 8 >Reporter: Andrei Pozolotin > Labels: easyfix, features > > 1) currently, plugin.xml descriptor is generated by extractors > which look basically in 2 places: > a) annotations > b) javadoc > in cases when plugin is written in "other java": scala, groovy, etc i.e. : > https://github.com/random-maven/bintray-maven-plugin > a) annotations work just fine > b) but javadoc descriptions are lost > https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html > 2) this request is to add extra field *description* to all mojo annotations > https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations > so for example: > /** > * Enable to perform deployment. > */ > @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) > becomes: > @Parameter( > description = "Enable to perform deployment.", > property = "bintray.performDeploy", > defaultValue = "true" > ) > it seems this feature requires minor effort, yet can result in major > improvement -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MPLUGIN-329) support for "description" in mojo annotations / extractors for plugin.xml
[ https://issues.apache.org/jira/browse/MPLUGIN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Pozolotin updated MPLUGIN-329: - Description: 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html 2) this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement was: 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement > support for "description" in mojo annotations / extractors for plugin.xml > - > > Key: MPLUGIN-329 > URL: https://issues.apache.org/jira/browse/MPLUGIN-329 > Project: Maven Plugin Tools > Issue Type: Bug > Components: maven-plugin-annotations, maven-plugin-tools-java >Affects Versions: 3.5 > Environment: java 8 >Reporter: Andrei Pozolotin > Labels: easyfix, features > > 1) currently, plugin.xml descriptor is generated by extractors > which look basically in 2 places: > a) annotations > b) javadoc > in cases when plugin is written in "other java": scala, groovy, etc i.e. : > https://github.com/random-maven/bintray-maven-plugin > a) annotations work just fine > b) but javadoc descriptions are lost > https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html > 2) this request is to add extra field *description* to all mojo annotations > https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations > so for example: > @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) > becomes: > @Parameter( > description = "Enable to perform deployment.", > property = "bintray.performDeploy", > defaultValue = "true" > ) > it seems this feature requires minor effort, yet can result in major > improvement -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MPLUGIN-329) support for "description" in mojo annotations / extractors for plugin.xml
Andrei Pozolotin created MPLUGIN-329: Summary: support for "description" in mojo annotations / extractors for plugin.xml Key: MPLUGIN-329 URL: https://issues.apache.org/jira/browse/MPLUGIN-329 Project: Maven Plugin Tools Issue Type: Bug Components: maven-plugin-annotations, maven-plugin-tools-java Affects Versions: 3.5 Environment: java 8 Reporter: Andrei Pozolotin 1) currently, plugin.xml descriptor is generated by extractors which look basically in 2 places: a) annotations b) javadoc in cases when plugin is written in "other java": scala, groovy, etc i.e. : https://github.com/random-maven/bintray-maven-plugin a) annotations work just fine b) but javadoc descriptions are lost https://random-maven.github.io/bintray-maven-plugin/deploy-mojo.html this request is to add extra field *description* to all mojo annotations https://github.com/apache/maven-plugin-tools/tree/master/maven-plugin-annotations/src/main/java/org/apache/maven/plugins/annotations so for example: @Parameter( property = "bintray.performDeploy", defaultValue = "true" ) becomes: @Parameter( description = "Enable to perform deployment.", property = "bintray.performDeploy", defaultValue = "true" ) it seems this feature requires minor effort, yet can result in major improvement -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323571#comment-323571 ] Andrei Pozolotin commented on MNG-3092: --- What do think abut this proposal: RFP: Version Range Policy http://mail-archives.apache.org/mod_mbox/maven-dev/201304.mbox/%3c5165a10f.50...@gmail.com%3E > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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=323329#comment-323329 ] Andrei Pozolotin commented on MRELEASE-431: --- maven should implement semantic versioning in the core http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf some plugins which are doing this: https://github.com/apache/aries/tree/trunk/versioning https://github.com/jeluard/semantic-versioning > 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 > > 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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323323#comment-323323 ] Andrei Pozolotin commented on MNG-3092: --- @Jason 1) do you think maven should follow OSGI semantic version model more closely? http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf that could be a base ground for maven ranges rules. 2) do you think version range resolver could be made into an extension which could be replaced via user plugin? thank you. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323322#comment-323322 ] Andrei Pozolotin commented on MNG-3092: --- @Kunalkumar re: your changed maven code * can you please share where is it? * can we collaborate on releasing it? * can it be incorporated in a form of "extension" (so there is no need for maven 3 re-install)? thank you. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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] (MINVOKER-153) @project.version@ is not substituted if it comes form invoked test parent
Andrei Pozolotin created MINVOKER-153:
-
Summary: @project.version@ is not substituted if it comes form
invoked test parent
Key: MINVOKER-153
URL: https://jira.codehaus.org/browse/MINVOKER-153
Project: Maven 2.x Invoker Plugin
Issue Type: Bug
Affects Versions: 1.8
Reporter: Andrei Pozolotin
1) here is a parent:
https://github.com/barchart/barchart-archon/blob/master/pom.xml
2) here is a app project under verify, which extends from parent:
https://github.com/barchart/barchart-service/blob/master/barchart-karaf-base-app/pom.xml
3) here is verification test for the app project
https://github.com/barchart/barchart-service/blob/master/barchart-karaf-base-app/verify/verify/pom.xml
NOTE: parent has 2 profiles which supposed to provide "integrationVersion"
depending if working in IDE or building in Jenkins:
https://github.com/barchart/barchart-archon/blob/master/pom.xml#L1282
{code}
build-human
!env.JENKINS_HOME
${integrationVersion}
process-ignored
build-robot
env.JENKINS_HOME
@project.version@
process-classes
{code}
PROBLEM:
when @project.version@ is mentioned in parent, it will not get substituted.
WORK AROUND:
need to copy/paste profiles from parent to verification project.
SOLUTION:
@project.version@ should be substituted everywhere.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320737#comment-320737
]
Andrei Pozolotin commented on SCM-709:
--
wow! :-) it it all that needed? is part of unit tests now? where can I get
snapshot to try this?
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317873#comment-317873
]
Andrei Pozolotin commented on SCM-709:
--
I just remembered that it worked fine with maven-release-plugin v 2.3.2 (and
whatever SCM dependency was there)
is there easy way to see what specific change to v 2.4 (and related SCM) broke
this?
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
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] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317822#comment-317822
]
Andrei Pozolotin commented on SCM-709:
--
I took a look. few ideas:
1) "/" feels like a hack; who guarantees its presence ?
2) could you differentiate via all of: File.exists() File.isFile()
File.isDirectory() ?
3) "/" probably should be File.separator ?
4) need File.getCanonicalFile() to guard against symlinks ?
5) need File.getAbsolutePath() to actually render File.separator suffix ?
6) only one of oldFilePath or newFilePath is actually present on file system
for File.exists() to work,
could be logic error in :: if ( status == ScmFileStatus.RENAMED ) {} :: block,
if treating both same way ?
7) if original issue is path/file overlap, may be should detect specifically
only that?
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
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] (SCM-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317801#comment-317801
]
Andrei Pozolotin commented on SCM-709:
--
I am curious what next steps would be?
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
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] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317454#comment-317454 ] Andrei Pozolotin commented on MRELEASE-812: --- Robert: thank you for looking into this; here is a test case: 1) repo to clone https://github.com/barchart/barchart-bugs 2) project with v 2.3.2, which works https://github.com/barchart/barchart-bugs/tree/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-01 and maven log https://raw.github.com/barchart/barchart-bugs/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-01/doc/mvn.log.txt run from eclipse: https://github.com/barchart/barchart-bugs/blob/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-01/build/maven-release.ant 3) project with v 2.4, which is broken https://github.com/barchart/barchart-bugs/tree/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-02 and maven log https://raw.github.com/barchart/barchart-bugs/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-02/doc/mvn.log.txt run from eclipse: https://github.com/barchart/barchart-bugs/blob/master/barchart-bugs-MRELEASE-812/build-tester/barchart-bugs-MRELEASE-812-case-02/build/maven-release.ant thank you. Andrei. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin >Priority: Critical > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- 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] (MRELEASE-812) "perform" does not commit tags, deploys snapshot instead of release
Andrei Pozolotin created MRELEASE-812: - Summary: "perform" does not commit tags, deploys snapshot instead of release Key: MRELEASE-812 URL: https://jira.codehaus.org/browse/MRELEASE-812 Project: Maven 2.x Release Plugin Issue Type: Bug Components: Git Affects Versions: 2.4 Reporter: Andrei Pozolotin Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt thank you very much for new release! http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E it seems we need an emergency fix: attached are 2 logs: 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 2) mvn-2.4.0.txt invocation that fails with 2.4 problem: "perform" does not commit tags, deploys snapshot instead of release here is project parent: http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom build is invoked both times with this: mvn --define resume=false release:prepare mvn --define resume=false release:perform -- 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] (MRELEASE-459) releaseProfiles has no effect without passing profiles in the command line
[ https://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=310325#comment-310325 ] Andrei Pozolotin commented on MRELEASE-459: --- thank you! > releaseProfiles has no effect without passing profiles in the command line > --- > > Key: MRELEASE-459 > URL: https://jira.codehaus.org/browse/MRELEASE-459 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.0-beta-8, 2.0-beta-9 >Reporter: Andreas Christoforides >Assignee: Robert Scholte > Labels: contributers-welcome, help-requested, > missing-integration-tests > Fix For: 2.4 > > Attachments: MRELEASE-459.1.patch, patch.txt > > > The releaseProfiles parameter on the perform goal is not taken into > consideration when no other profiles are passed in the command line. In other > words, the current code only uses the value of the parameter if you have > additional profiles passed in. > Example: > mvn release:perform -P someProfile (uses releaseProfiles value) > mvn release:perform (does NOT use releaseProfiles value) > The plugin should use the parameter even if no other profiles are passed. It > should actually encourage release profiles configured in your POM as opposed > to arbitrary profiles passed in the command line. > I have included a patch that uses the releaseProfiles parameter regardless of > any profiles passed in the command line. -- 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] (SUREFIRE-888) plain should inject "\n" after per-method test line items in console & files
[ https://jira.codehaus.org/browse/SUREFIRE-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306488#comment-306488 ] Andrei Pozolotin commented on SUREFIRE-888: --- thank you! > plain should inject "\n" after per-method test > line items in console & files > - > > Key: SUREFIRE-888 > URL: https://jira.codehaus.org/browse/SUREFIRE-888 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12 > Environment: java 1.7.0_05 > maven 3.0.4 >Reporter: Andrei Pozolotin >Assignee: Kristian Rosenvold > Fix For: 2.13.0 > > > the following pom > https://github.com/carrot-garden/sql_mybatis-koans/blob/master/pom.xml > when run like this > mvn clean verify -P run-test-koans-h2 > produces reports on console like one shown at the bottom; > but surefire "forgets" to separate per-method test report entreis with EOL, > you would expect it to look like this instead: > learnToQueryViaXmlMapperReturningHashMap(..) Time elapsed: 1.072 sec > learnToQueryMapperReturningHashMapWithParameterInput(..) Time elapsed: 0.005 > sec > learnToQueryViaXmlMapperReturningListOfHashMaps(..) Time elapsed: 0.036 sec > BTW this used to look OK in the past; > --- > > > T E S T S > > > --- > > > Concurrency config is parallel='none', perCoreThreadCount=true, > threadCount=2, useUnlimitedThreads=false > > Running net.thornydev.mybatis.test.koan01.Koan01 > > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec > > > learnBasicConfigurationSetup(net.thornydev.mybatis.test.koan01.Koan01) Time > elapsed: 0.1 secRunning net.thornydev.mybatis.test.koan02.Koan02 > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.113 sec > learnToQueryViaXmlMapperReturningHashMap(net.thornydev.mybatis.test.koan02.Koan02) > Time elapsed: 1.072 > seclearnToQueryMapperReturningHashMapWithParameterInput(net.thornydev.mybatis.test.koan02.Koan02) > Time elapsed: 0.005 > seclearnToQueryViaXmlMapperReturningListOfHashMaps(net.thornydev.mybatis.test.koan02.Koan02) > Time elapsed: 0.036 secRunning net.thornydev.mybatis.test.koan03.Koan03 > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.067 sec > learnToQueryViaXmlMapperReturningHashMapOfCountriesKeyedById(net.thornydev.mybatis.test.koan03.Koan03) > Time elapsed: 0.026 > seclearnToQueryViaXmlMapperReturningCountryDomainObject(net.thornydev.mybatis.test.koan03.Koan03) > Time elapsed: 0.008 > seclearnToQueryViaXmlMapperReturningListOfCountries(net.thornydev.mybatis.test.koan03.Koan03) > Time elapsed: 0.033 secRunning net.thornydev.mybatis.test.koan04.Koan04 > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec > learnToQueryViaXmlMapperReturningHashMapOfCountriesKeyedById(net.thornydev.mybatis.test.koan04.Koan04) > Time elapsed: 0.02 > seclearnToQueryViaXmlMapperReturningCountryDomainObject(net.thornydev.mybatis.test.koan04.Koan04) > Time elapsed: 0.003 > seclearnToQueryViaXmlMapperReturningListOfCountries(net.thornydev.mybatis.test.koan04.Koan04) > Time elapsed: 0.017 secRunning net.thornydev.mybatis.test.koan05.Koan05 > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec > learnToQueryViaMapperClassReturningCountryDomainObject(net.thornydev.mybatis.test.koan05.Koan05) > Time elapsed: 0.011 > seclearnToQueryViaMapperClassReturningListOfCountries(net.thornydev.mybatis.test.koan05.Koan05) > Time elapsed: 0.014 > seclearnToQueryViaMapperClassReturningHashMapOfCountriesKeyedById(net.thornydev.mybatis.test.koan05.Koan05) > Time elapsed: 0.027 secRunning
[jira] (MRELEASE-459) releaseProfiles has no effect without passing profiles in the command line
[
https://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306397#comment-306397
]
Andrei Pozolotin commented on MRELEASE-459:
---
fyi: this is still a problem as of 2.3.2;
hey, this soon will make it into a book of records! :-)
it will be named: "the curse of the maven release plugin"
http://stackoverflow.com/questions/3291938/maven-release-plugin-ignores-releaseprofile
workaround is still the same: put a dummy profile in settings.xml
{code:title=settings.xml|borderStyle=solid}
default
default
{code}
> releaseProfiles has no effect without passing profiles in the command line
> ---
>
> Key: MRELEASE-459
> URL: https://jira.codehaus.org/browse/MRELEASE-459
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-8, 2.0-beta-9
>Reporter: Andreas Christoforides
> Labels: contributers-welcome, help-requested,
> missing-integration-tests
> Attachments: MRELEASE-459.1.patch, patch.txt
>
>
> The releaseProfiles parameter on the perform goal is not taken into
> consideration when no other profiles are passed in the command line. In other
> words, the current code only uses the value of the parameter if you have
> additional profiles passed in.
> Example:
> mvn release:perform -P someProfile (uses releaseProfiles value)
> mvn release:perform (does NOT use releaseProfiles value)
> The plugin should use the parameter even if no other profiles are passed. It
> should actually encourage release profiles configured in your POM as opposed
> to arbitrary profiles passed in the command line.
> I have included a patch that uses the releaseProfiles parameter regardless of
> any profiles passed in the command line.
--
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] (SUREFIRE-888) plain should inject "\n" after per-method test line items in console & files
Andrei Pozolotin created SUREFIRE-888: - Summary: plain should inject "\n" after per-method test line items in console & files Key: SUREFIRE-888 URL: https://jira.codehaus.org/browse/SUREFIRE-888 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.12 Environment: java 1.7.0_05 maven 3.0.4 Reporter: Andrei Pozolotin the following pom https://github.com/carrot-garden/sql_mybatis-koans/blob/master/pom.xml when run like this mvn clean verify -P run-test-koans-h2 produces reports on console like one shown at the bottom; but surefire "forgets" to separate per-method test report entreis with EOL, you would expect it to look like this instead: learnToQueryViaXmlMapperReturningHashMap(..) Time elapsed: 1.072 sec learnToQueryMapperReturningHashMapWithParameterInput(..) Time elapsed: 0.005 sec learnToQueryViaXmlMapperReturningListOfHashMaps(..) Time elapsed: 0.036 sec BTW this used to look OK in the past; --- T E S T S --- Concurrency config is parallel='none', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false Running net.thornydev.mybatis.test.koan01.Koan01 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec learnBasicConfigurationSetup(net.thornydev.mybatis.test.koan01.Koan01) Time elapsed: 0.1 secRunning net.thornydev.mybatis.test.koan02.Koan02 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.113 sec learnToQueryViaXmlMapperReturningHashMap(net.thornydev.mybatis.test.koan02.Koan02) Time elapsed: 1.072 seclearnToQueryMapperReturningHashMapWithParameterInput(net.thornydev.mybatis.test.koan02.Koan02) Time elapsed: 0.005 seclearnToQueryViaXmlMapperReturningListOfHashMaps(net.thornydev.mybatis.test.koan02.Koan02) Time elapsed: 0.036 secRunning net.thornydev.mybatis.test.koan03.Koan03 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.067 sec learnToQueryViaXmlMapperReturningHashMapOfCountriesKeyedById(net.thornydev.mybatis.test.koan03.Koan03) Time elapsed: 0.026 seclearnToQueryViaXmlMapperReturningCountryDomainObject(net.thornydev.mybatis.test.koan03.Koan03) Time elapsed: 0.008 seclearnToQueryViaXmlMapperReturningListOfCountries(net.thornydev.mybatis.test.koan03.Koan03) Time elapsed: 0.033 secRunning net.thornydev.mybatis.test.koan04.Koan04 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec learnToQueryViaXmlMapperReturningHashMapOfCountriesKeyedById(net.thornydev.mybatis.test.koan04.Koan04) Time elapsed: 0.02 seclearnToQueryViaXmlMapperReturningCountryDomainObject(net.thornydev.mybatis.test.koan04.Koan04) Time elapsed: 0.003 seclearnToQueryViaXmlMapperReturningListOfCountries(net.thornydev.mybatis.test.koan04.Koan04) Time elapsed: 0.017 secRunning net.thornydev.mybatis.test.koan05.Koan05 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec learnToQueryViaMapperClassReturningCountryDomainObject(net.thornydev.mybatis.test.koan05.Koan05) Time elapsed: 0.011 seclearnToQueryViaMapperClassReturningListOfCountries(net.thornydev.mybatis.test.koan05.Koan05) Time elapsed: 0.014 seclearnToQueryViaMapperClassReturningHashMapOfCountriesKeyedById(net.thornydev.mybatis.test.koan05.Koan05) Time elapsed: 0.027 secRunning net.thornydev.mybatis.test.koan06.Koan06 Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec learnToQueryWithMultipleParamsWithAnnotatedNames(net.thornydev.mybatis.test.koan06.Koan06) Time elapsed: 0.012 seclearnToQueryWithDomainSpecificRangeParam(net.thornydev.mybatis.test.koan06.Koan06) Time elapsed: 0.008 seclearnToQueryWithRowBounds(net.thornydev.mybatis.test.koan06.Koan06) Time elapsed: 0.011 seclearnToQueryMapperClassWithRowBounds(net.thornydev.mybati
[jira] (MRELEASE-724) Release plugin doesn't honor profiles defined in user settings
[
https://jira.codehaus.org/browse/MRELEASE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287273#comment-287273
]
Andrei Pozolotin commented on MRELEASE-724:
---
1) same problem here;
2) I think this has to do with the following:
the inner maven invocation:
[DEBUG] Executing: /bin/sh -c cd /Users/arnaud/Code/eXo/cloud-management &&
/Users/arnaud/Applications/apache-maven-3.0.4-RC3/bin/mvn -X -D
maven.repo.local=/Users/arnaud/.m2/repository -s
/private/var/folders/t0/rlgvq9wj557dbt5zbxwg3c34gn/T/release-settings1260821738839931094.xml
-P exo-private,exo-staging,exo-central,local-properties clean verify
uses generated-on-the-fly settings.xml such as:
release-settings1260821738839931094.xml
if you intercept this file like this:
while : ; do cp release-settings*.xml release-settings.xml.tmp ; sleep 0.01
; done
and look inside, you will see that it does not contain any profile definitions
that it should have imported from ${user.home}/.m2/settings.xml
> Release plugin doesn't honor profiles defined in user settings
> --
>
> Key: MRELEASE-724
> URL: https://jira.codehaus.org/browse/MRELEASE-724
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.2.2
>Reporter: Arnaud Heritier
>Priority: Critical
> Attachments: MRELEASE-724.log
>
>
> We tried to upgrade the release plugin from 2.2.1 to 2.2.2 and it broke our
> release.
> We don't define repositories (especially private ones) in our pom but in our
> developers settings (activated from command line or more often in
> activeProfiles)
> Releasing this project fails with :
> {code}
> arnaud@mbp-arnaud:~/Code/eXo/cloud-management (git:develop %)$ mvn
> release:prepare -DdryRun=true
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> ...
> [INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @
> cloud-management-parent ---
> [INFO] Resuming release from phase 'run-preparation-goals'
> [INFO] Executing preparation goals - since this is simulation mode it is
> running against the original project, not the rewritten ones
> [INFO] Executing goals 'clean verify'...
> [WARNING] Maven will be executed in interactive mode, but no input stream has
> been configured for this MavenInvoker instance.
> [INFO] [INFO] Scanning for projects...
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Build Order:
> ...
> [INFO] [INFO]
>
> [INFO] [INFO] Building eXo Cloud Management :: Parent 1.1-M4-SNAPSHOT
> [INFO] [INFO]
>
> ...
> [INFO] [INFO] --- maven-license-plugin:1.9.0:check (check-headers) @
> cloud-management-parent ---
> [INFO] [WARNING] The POM for
> org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 is missing, no
> dependency information available
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Summary:
> [INFO] [INFO]
> [INFO] [INFO] eXo Cloud Management :: Parent FAILURE
> [1.257s]
> ...
> [INFO] [INFO]
>
> [INFO] [INFO] BUILD FAILURE
> [INFO] [INFO]
>
> ...
> [INFO] [INFO]
>
> [INFO] [WARNING] The requested profile "exo-central" could not be activated
> because it does not exist.
> [INFO] [WARNING] The requested profile "local-properties" could not be
> activated because it does not exist.
> [INFO] [WARNING] The requested profile "exo-private" could not be activated
> because it does not exist.
> [INFO] [WARNING] The requested profile "exo-staging" could not be activated
> because it does not exist.
> [INFO] [ERROR] Failed to execute goal
> com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
> (check-headers) on project cloud-management-parent: Execution check-headers
> of goal com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
> failed: Plugin com.mycila.maven-license-plugin:maven-license-plugin:1.9.0 or
> one of its dependencies could not be resolved: Failure to find
> org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 in
> http://repository.exoplatform.org/public was cached in the local repository,
> resolution will not be reattempted until the update interval of exo-fr-mirror
> has elapsed or updates are forced -> [Help 1]
> [INFO] [ER
[jira] Commented: (MNG-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253017#action_253017 ] Andrei Pozolotin commented on MNG-4452: --- Leon: I tried to send you email (listed on this site); but it got bounced; I wanted to ask you if you were able to solve the following nar issue: https://issues.sonatype.org/browse/NAR-181 thank you; Andrei > Metadata for snapshots should include classifier > > > Key: MNG-4452 > URL: http://jira.codehaus.org/browse/MNG-4452 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-alpha-4 >Reporter: Paul Benedict >Assignee: Benjamin Bentmann > Fix For: 3.0 > > Attachments: nar-artifact-list.txt, nar-maven-metadata.xml, output > > > Please see the whole conversation here: > http://old.nabble.com/Multi-Platform-snapshots-td25295999.html > Essentially, an artifact's classifier isn't included in the repository's > metadata of a snapshot. This makes it difficult (impossible?) to deploy > multiply snapshots with different classifiers. The primary use case is to > continuously build an artifact for different environments. -- 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-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253016#action_253016 ] Andrei Pozolotin commented on MNG-4452: --- Leon: according to this: https://issues.sonatype.org/browse/NEXUS-4055 sonatype folks fixed this in trunk; you may want to build nexus; Andrei > Metadata for snapshots should include classifier > > > Key: MNG-4452 > URL: http://jira.codehaus.org/browse/MNG-4452 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-alpha-4 >Reporter: Paul Benedict >Assignee: Benjamin Bentmann > Fix For: 3.0 > > Attachments: nar-artifact-list.txt, nar-maven-metadata.xml, output > > > Please see the whole conversation here: > http://old.nabble.com/Multi-Platform-snapshots-td25295999.html > Essentially, an artifact's classifier isn't included in the repository's > metadata of a snapshot. This makes it difficult (impossible?) to deploy > multiply snapshots with different classifiers. The primary use case is to > continuously build an artifact for different environments. -- 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-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253015#action_253015 ] Andrei Pozolotin commented on MNG-4452: --- Leon: in my case: 1) my "real repo" is sonaytpe oss; 2) my "proxy repo" is internal corporate repo which was going after sonatype oss; Andrei > Metadata for snapshots should include classifier > > > Key: MNG-4452 > URL: http://jira.codehaus.org/browse/MNG-4452 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-alpha-4 >Reporter: Paul Benedict >Assignee: Benjamin Bentmann > Fix For: 3.0 > > Attachments: nar-artifact-list.txt, nar-maven-metadata.xml, output > > > Please see the whole conversation here: > http://old.nabble.com/Multi-Platform-snapshots-td25295999.html > Essentially, an artifact's classifier isn't included in the repository's > metadata of a snapshot. This makes it difficult (impossible?) to deploy > multiply snapshots with different classifiers. The primary use case is to > continuously build an artifact for different environments. -- 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-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252332#action_252332 ] Andrei Pozolotin commented on MNG-4452: --- Leon: my woraround is use direct repo access and NOT to use repo-to-repo proxy: https://issues.sonatype.org/browse/NEXUS-4055 Andrei > Metadata for snapshots should include classifier > > > Key: MNG-4452 > URL: http://jira.codehaus.org/browse/MNG-4452 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-alpha-4 >Reporter: Paul Benedict >Assignee: Benjamin Bentmann > Fix For: 3.0 > > Attachments: nar-artifact-list.txt, nar-maven-metadata.xml, output > > > Please see the whole conversation here: > http://old.nabble.com/Multi-Platform-snapshots-td25295999.html > Essentially, an artifact's classifier isn't included in the repository's > metadata of a snapshot. This makes it difficult (impossible?) to deploy > multiply snapshots with different classifiers. The primary use case is to > continuously build an artifact for different environments. -- 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-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250907#action_250907 ] Andrei Pozolotin commented on MNG-4965: --- done: https://issues.sonatype.org/browse/NEXUS-4055 > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- 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-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250904#action_250904 ] Andrei Pozolotin commented on MNG-4965: --- actually, I was able to reproduce the issue with 3.0.1: 1) if I run mvn against "real" snapshot repo - all works; 2) but if I run mvn against a nexus which is a proxy to the "real" repo - then the problems are as I described; > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- 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-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250905#action_250905 ] Andrei Pozolotin commented on MNG-4965: --- proxy nexus info: Sonatype Nexus Open Source Edition, Version: 1.8.0.1 > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- 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-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250896#action_250896 ] Andrei Pozolotin commented on MNG-4965: --- Benjamin: thanks for looking into this; yes, you are right! (although I was sure I triple checked everything before filing a bug) thanks again! Andrei > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- 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-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250858#action_250858 ] Andrei Pozolotin commented on MNG-4452: --- forgot to mention: of course, this relates to SNAPSHOT artifacts only > Metadata for snapshots should include classifier > > > Key: MNG-4452 > URL: http://jira.codehaus.org/browse/MNG-4452 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-alpha-4 >Reporter: Paul Benedict >Assignee: Benjamin Bentmann > Fix For: 3.0 > > > Please see the whole conversation here: > http://old.nabble.com/Multi-Platform-snapshots-td25295999.html > Essentially, an artifact's classifier isn't included in the repository's > metadata of a snapshot. This makes it difficult (impossible?) to deploy > multiply snapshots with different classifiers. The primary use case is to > continuously build an artifact for different environments. -- 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: (MNG-4965) resolver fails to find artifacts with classifiers from previous deployments
resolver fails to find artifacts with classifiers from previous deployments --- Key: MNG-4965 URL: http://jira.codehaus.org/browse/MNG-4965 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.1 Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, windows x86, windows x86_64 jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 maven 3.0.1 Reporter: Andrei Pozolotin please see my comment and detailed example to the issue MNG-4452 http://jira.codehaus.org/browse/MNG-4452 -- 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-4452) Metadata for snapshots should include classifier
[
http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250857#action_250857
]
Andrei Pozolotin commented on MNG-4452:
---
I guess, I must clarify:
1) yes I see in 3.0.1 that shapshots metadata does includes classifier;
2) the problem is that resolver still does not find attached artifacts form
previous deployments;
for example, this is repo metadata after 2 deployments:
note, that artifacts of interest are (build 83 and 84):
com.barchart.udt:barchart-udt4:1.0.2-20110108.023638-83:i386-Linux-g++-jni:nar
com.barchart.udt:barchart-udt4:1.0.2-20110108.023723-84:amd64-Linux-g++-jni:nar
##
com.barchart.udt
barchart-udt4
1.0.2-SNAPSHOT
−
−
20110108.023723
84
20110108023723
−
−
jar
1.0.2-20110108.023723-84
20110108023723
−
pom
1.0.2-20110108.023723-84
20110108023723
−
noarch
nar
1.0.2-20110108.023723-84
20110108023723
−
i386-Linux-g++-jni
nar
1.0.2-20110108.023638-83
20110108023638
−
amd64-Linux-g++-jni
nar
1.0.2-20110108.023723-84
20110108023723
##
and this is dependency declaration, I want 1 jar and 2 nar, platform dependent:
##
com.barchart.udt
barchart-udt4
${barchart.version}
jar
com.barchart.udt
barchart-udt4
${barchart.version}
i386-Linux-g++-jni
nar
com.barchart.udt
barchart-udt4
${barchart.version}
amd64-Linux-g++-jni
nar
##
and this is the error:
##
[INFO] Scanning for projects...
[INFO] snapshot com.barchart.udt:barchart-udt4-parent:1.0.0-SNAPSHOT: checking
for updates from sonatype-nexus-snapshots
[INFO]
[INFO] Building Unnamed -
com.barchart.udt:barchart-udt4-bundle:jar:1.0.0-SNAPSHOT
[INFO]task-segment: [validate]
[INFO]
[INFO] snapshot com.barchart.udt:barchart-udt4:1.0.2-SNAPSHOT: checking for
updates from sonatype-nexus-snapshots
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/barchart/udt/barchart-udt4/1.0.2-SNAPSHOT/barchart-udt4-1.0.2-20110108.023723-84.pom
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/barchart/udt/barchart-udt4/1.0.2-SNAPSHOT/barchart-udt4-1.0.2-20110108.023723-84.jar
78K downloaded (barchart-udt4-1.0.2-20110108.023723-84.jar)
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/barchart/udt/barchart-udt4/1.0.2-SNAPSHOT/barchart-udt4-1.0.2-20110108.023723-84-i386-Linux-g++-jni.nar
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/barchart/udt/barchart-udt4/1.0.2-SNAPSHOT/barchart-udt4-1.0.2-20110108.023723-84-amd64-Linux-g++-jni.nar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
##
in other words, the resolver tries to find
barchart-udt4-1.0.2-20110108.023723-84-i386-Linux-g++-jni.nar
and
barchart-udt4-1.0.2-20110108.023723-84-amd64-Linux-g++-jni.nar
both from latest build #84, instead of looking through the versioning
in order to find the file that actually exists in build #83:
barchart-udt4-1.0.2-20110108.023638-83:i386-Linux-g++-jni.nar
> Metadata for snapshots should include classifier
>
>
> Key: MNG-4452
> URL: http://jira.codehaus.org/browse/MNG-4452
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.2.1, 3.0-alpha-4
>Reporter: Paul Benedict
>Assignee: Benjamin Bentmann
> Fix For: 3.0
>
>
> Please see the whole conversation here:
> http://old.nabble.com/Multi-Platform-snapshots-td25295999.html
> Essentially, an artifact's classifier isn't included in the repository's
> metadata of a snapshot. This makes it difficult (impossible?) to deploy
> multiply snapshots with different classifiers. The primary use case is to
> continuously build an artifact for different environments.
--
This message is aut
[jira] Commented: (MNG-4452) Metadata for snapshots should include classifier
[ http://jira.codehaus.org/browse/MNG-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250856#action_250856 ] Andrei Pozolotin commented on MNG-4452: --- Benjamin: just to confirm, is it fixed in 3.0.1? the issue still affecting me thanks; Andrei > Metadata for snapshots should include classifier > > > Key: MNG-4452 > URL: http://jira.codehaus.org/browse/MNG-4452 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.2.1, 3.0-alpha-4 >Reporter: Paul Benedict >Assignee: Benjamin Bentmann > Fix For: 3.0 > > > Please see the whole conversation here: > http://old.nabble.com/Multi-Platform-snapshots-td25295999.html > Essentially, an artifact's classifier isn't included in the repository's > metadata of a snapshot. This makes it difficult (impossible?) to deploy > multiply snapshots with different classifiers. The primary use case is to > continuously build an artifact for different environments. -- 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
