[jira] (MDEP-404) mvn 3.0.4 is extreemly slow with a large number of "import" dependencies.
[ https://jira.codehaus.org/browse/MDEP-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZILVINAS VILUTIS updated MDEP-404: -- Attachment: dep-tree-maven-3.0.5.log dep-tree-maven-2.2.1.log Still significant difference exists, please see logs: [^dep-tree-maven-2.2.1.log] - takes 13s using maven 2.2.1 [^dep-tree-maven-3.0.5.log] - takes 55s using maven 3.0.5 > mvn 3.0.4 is extreemly slow with a large number of "import" dependencies. > - > > Key: MDEP-404 > URL: https://jira.codehaus.org/browse/MDEP-404 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: tree >Affects Versions: 2.4 > Environment: Linux skhalipau.internal.corp 3.2.0-32-generic > #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Siarhei Khalipau > Attachments: dep-tree-maven-2.2.1.log, dep-tree-maven-3.0.5.log, > jprofiler_mvn_dependency_tree.tar.bz2, mvn_2.2.1_dependency_tree.log, > mvn_3.0.4_dependency_tree.log, stacktrace.txt > > > In comparison with maven 2.2.1 resolving of dependencies with scope "import" > is very slow in maven 3. > Example results for "mvn dependency:tree" in one my project: maven 2.2.1 says > "[INFO] Total time: 8 seconds" but 3.0.4 "[INFO] Total time: 13:02.069s". > Resulting trees are identical. > I profiled the code and found that maven 3 did not cache parsed pom files but > it reads and parses one pom file every time when it find it in imported > dependencies. So the method > org.apache.maven.model.building.DefaultModelBuilder.importDependencyManagement() > is called many times for one artifact. There is JProfiler result for "mvn > dependency:tree" in attachment. -- 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-5481) Prevent dependency with too recent bytecode from creeping in unnoticed
Baptiste Mathus created MNG-5481: Summary: Prevent dependency with too recent bytecode from creeping in unnoticed Key: MNG-5481 URL: https://jira.codehaus.org/browse/MNG-5481 Project: Maven 2 & 3 Issue Type: Improvement Components: POM Reporter: Baptiste Mathus Priority: Minor As a followup to http://www.mail-archive.com/dev@maven.apache.org/msg96659.html here's a patch that configures an additional enforcer rule to prevent using dependencies that were compiled with a compiler more recent than the maximum allowed. The proposed patch patches the maven-plugins/pom.xml but if you think this should go somewhere else, don't hesitate to ask. Cheers PS : not perfectly sure this is the right JIRA project, please just tell me if this should be relocated. -- 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-5481) Prevent dependency with too recent bytecode from creeping in unnoticed
[ https://jira.codehaus.org/browse/MNG-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baptiste Mathus updated MNG-5481: - Attachment: MNG-5481.patch Patch that should be applied on the maven-plugins/pom.xml file. Full informations: maven-plugins]$ svn info Path: . Working Copy Root Path: /home/tiste/Dropbox/repos/perso/maven-plugins URL: https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-plugins Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1484404 Node Kind: directory Schedule: normal Last Changed Author: hboutemy Last Changed Rev: 1481654 Last Changed Date: 2013-05-12 23:46:44 +0200 (Sun, 12 May 2013) > Prevent dependency with too recent bytecode from creeping in unnoticed > -- > > Key: MNG-5481 > URL: https://jira.codehaus.org/browse/MNG-5481 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: POM >Reporter: Baptiste Mathus >Priority: Minor > Attachments: MNG-5481.patch > > > As a followup to > http://www.mail-archive.com/dev@maven.apache.org/msg96659.html here's a patch > that configures an additional enforcer rule to prevent using dependencies > that were compiled with a compiler more recent than the maximum allowed. > The proposed patch patches the maven-plugins/pom.xml but if you think this > should go somewhere else, don't hesitate to ask. > Cheers > PS : not perfectly sure this is the right JIRA project, please just tell me > if this should be relocated. -- 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-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=325294#comment-325294 ] Christoph Kutzinski commented on MRELEASE-812: -- Contrary to other comments here I had the same problem with maven-release-plugin 2.3.2. The workaround described here http://www.shredzone.de/cilla/page/373/maven-release-plugin-and-git-fix.html - i.e. setting LANG to english - worked. > "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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-997) Support classpath resources in suiteXmlFiles
Mark Hobson created SUREFIRE-997:
Summary: Support classpath resources in suiteXmlFiles
Key: SUREFIRE-997
URL: https://jira.codehaus.org/browse/SUREFIRE-997
Project: Maven Surefire
Issue Type: Improvement
Components: TestNG support
Affects Versions: 2.14.1
Reporter: Mark Hobson
The TestNG {{suiteXmlFiles}} configuration parameter is of type {{File}} and as
such only supports suite XML files relative to the current project.
It would be handy to be able to reference suite XML files in other test
dependencies by using classpath resources. This would provide an explicit
method of executing tests from dependencies rather than the scanning mechanism
added in SUREFIRE-569.
--
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] (SUREFIRE-997) Support classpath resources in suiteXmlFiles
[
https://jira.codehaus.org/browse/SUREFIRE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hobson updated SUREFIRE-997:
-
Description:
The TestNG {{suiteXmlFiles}} configuration parameter is of type {{File}} and as
such only supports suite XML files relative to the current project.
It would be handy to be able to reference suite XML files in other test
dependencies by using classpath resources. This would provide an explicit
method of executing tests from dependencies rather than the scanning mechanism
added in SUREFIRE-569.
was:
The TestNG {{suiteXmlFiles}} configuration parameter is of type {{File}} and as
such only supports suite XML files relative to the current project.
It would be handy to be able to reference suite XML files in other test
dependencies by using classpath resources. This would provide an explicit
method of executing tests from dependencies rather than the scanning mechanism
added in SUREFIRE-569.
> Support classpath resources in suiteXmlFiles
>
>
> Key: SUREFIRE-997
> URL: https://jira.codehaus.org/browse/SUREFIRE-997
> Project: Maven Surefire
> Issue Type: Improvement
> Components: TestNG support
>Affects Versions: 2.14.1
>Reporter: Mark Hobson
>
> The TestNG {{suiteXmlFiles}} configuration parameter is of type {{File}} and
> as such only supports suite XML files relative to the current project.
> It would be handy to be able to reference suite XML files in other test
> dependencies by using classpath resources. This would provide an explicit
> method of executing tests from dependencies rather than the scanning
> mechanism added in SUREFIRE-569.
--
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] (SUREFIRE-997) Support classpath resources in suiteXmlFiles
[
https://jira.codehaus.org/browse/SUREFIRE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hobson updated SUREFIRE-997:
-
Description:
The TestNG {{suiteXmlFiles}} configuration parameter is of type {{File}} and as
such only supports suite XML files relative to the current project.
It would be handy to be able to reference suite XML files in other test
dependencies by using classpath resources. This would provide an explicit
method of executing tests from dependencies rather than the scanning mechanism
added in SUREFIRE-569.
was:
The TestNG {{suiteXmlFiles}} configuration parameter is of type {{File}} and as
such only supports suite XML files relative to the current project.
It would be handy to be able to reference suite XML files in other test
dependencies by using classpath resources. This would provide an explicit
method of executing tests from dependencies rather than the scanning mechanism
added in SUREFIRE-569.
> Support classpath resources in suiteXmlFiles
>
>
> Key: SUREFIRE-997
> URL: https://jira.codehaus.org/browse/SUREFIRE-997
> Project: Maven Surefire
> Issue Type: Improvement
> Components: TestNG support
>Affects Versions: 2.14.1
>Reporter: Mark Hobson
>
> The TestNG {{suiteXmlFiles}} configuration parameter is of type {{File}} and
> as such only supports suite XML files relative to the current project.
> It would be handy to be able to reference suite XML files in other test
> dependencies by using classpath resources. This would provide an explicit
> method of executing tests from dependencies rather than the scanning
> mechanism added in SUREFIRE-569.
--
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] (MASSEMBLY-554) DependencySet unpackOptions 'filtered' causes unpack not to work
[ https://jira.codehaus.org/browse/MASSEMBLY-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325296#comment-325296 ] Arnaud Heritier commented on MASSEMBLY-554: --- I met also this inconsistent behavior. > DependencySet unpackOptions 'filtered' causes unpack not to work > > > Key: MASSEMBLY-554 > URL: https://jira.codehaus.org/browse/MASSEMBLY-554 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 2.2 > Environment: Ubuntu 10.10 Linux, x86-64. >Reporter: Dave Combs > Attachments: example.zip > > > In 2.2-beta-4, the dependencySet option 'filtered' does not appear to work. > Files from a dependency end up in the right place (under / in the fragment > below), but the filters are not applied. In 2.2 it is worse--the files are > correctly filtered, but a directory of the same name as the archive from > which they came (com.kaazing.gateway.assembly.core.tar.gz below) is included > in the output under /, rather than just the contents of the archive, and the > filtered files appear there. It's as though the archive is exploded in place > under its own name. > > / > true > > true > > > > com.kaazing.gateway.core:com.kaazing.gateway.assembly.core:tar.gz:bin > > > This makes the filtering option essentially unusable, since I can't find a > way to eliminate this top-level directory creation. -- 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] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325297#comment-325297
]
Thorsten Gawantka commented on MCOMPILER-203:
-
An example for this more than suboptimal behavior is the annotation processor
for the static static metamodel generator of eclipselink. This processor will
add the complete eclipselink dependencies to the compile-classpath which is
IMHO MORE than suboptimal.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
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] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325297#comment-325297
]
Thorsten Gawantka edited comment on MCOMPILER-203 at 5/20/13 7:02 AM:
--
An example for this more than suboptimal behavior is the annotation processor
for the static static metamodel generator of eclipselink. This processor will
add the complete eclipselink dependencies to the compile-classpath which is
IMHO MORE than suboptimal.
Oh also the version 3.1 of maven-compiler-plugin is affected ;-)
was (Author: thgaw):
An example for this more than suboptimal behavior is the annotation
processor for the static static metamodel generator of eclipselink. This
processor will add the complete eclipselink dependencies to the
compile-classpath which is IMHO MORE than suboptimal.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
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] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325297#comment-325297
]
Thorsten Gawantka edited comment on MCOMPILER-203 at 5/20/13 7:03 AM:
--
An example for this more than suboptimal behavior is the annotation processor
for the static static metamodel generator of eclipselink. This processor will
add the complete eclipselink dependencies to the compile-classpath which is
IMHO MORE than suboptimal.
Also the version 3.1 of maven-compiler-plugin is affected ;-)
was (Author: thgaw):
An example for this more than suboptimal behavior is the annotation
processor for the static static metamodel generator of eclipselink. This
processor will add the complete eclipselink dependencies to the
compile-classpath which is IMHO MORE than suboptimal.
Oh also the version 3.1 of maven-compiler-plugin is affected ;-)
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
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] (MSKINS-72) Add copyright notice position option
[
https://jira.codehaus.org/browse/MSKINS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSKINS-72:
Assignee: Michael Osipov (was: Olivier Lamy)
> Add copyright notice position option
>
>
> Key: MSKINS-72
> URL: https://jira.codehaus.org/browse/MSKINS-72
> Project: Maven Skins
> Issue Type: New Feature
> Components: Fluido Skin
>Affects Versions: fluido-1.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: fluido-1.3.1
>
>
> The default skin has the copyright notice on the right-hand side of the
> screen. This has unfortunately changed in fluido skin.
> Add a {{}} element to site.xml/custom/fluidoSkin with left
> or right as values.
> IMHO default should be as in default skin.
> If current state will be retained, the right position has to be added to
> [this
> line|http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/src/main/resources/META-INF/maven/site.vm?view=markup#l1055].
> Swap {{class="row span12"}} to {{class="pull-right"}}.
--
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] (MSKINS-72) Add copyright notice position option
[
https://jira.codehaus.org/browse/MSKINS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-72:
-
Attachment: mylyn-context.zip
> Add copyright notice position option
>
>
> Key: MSKINS-72
> URL: https://jira.codehaus.org/browse/MSKINS-72
> Project: Maven Skins
> Issue Type: New Feature
> Components: Fluido Skin
>Affects Versions: fluido-1.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: fluido-1.3.1
>
> Attachments: MSKINS-72.patch, mylyn-context.zip
>
>
> The default skin has the copyright notice on the right-hand side of the
> screen. This has unfortunately changed in fluido skin.
> Add a {{}} element to site.xml/custom/fluidoSkin with left
> or right as values.
> IMHO default should be as in default skin.
> If current state will be retained, the right position has to be added to
> [this
> line|http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/src/main/resources/META-INF/maven/site.vm?view=markup#l1055].
> Swap {{class="row span12"}} to {{class="pull-right"}}.
--
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] (MSKINS-72) Add copyright notice position option
[
https://jira.codehaus.org/browse/MSKINS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325305#comment-325305
]
Michael Osipov commented on MSKINS-72:
--
I am not able to apply the patch myself: 403 Forbidden. Please apply patch
unless ACL has been clarified.
> Add copyright notice position option
>
>
> Key: MSKINS-72
> URL: https://jira.codehaus.org/browse/MSKINS-72
> Project: Maven Skins
> Issue Type: New Feature
> Components: Fluido Skin
>Affects Versions: fluido-1.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: fluido-1.3.1
>
> Attachments: MSKINS-72.patch, mylyn-context.zip
>
>
> The default skin has the copyright notice on the right-hand side of the
> screen. This has unfortunately changed in fluido skin.
> Add a {{}} element to site.xml/custom/fluidoSkin with left
> or right as values.
> IMHO default should be as in default skin.
> If current state will be retained, the right position has to be added to
> [this
> line|http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/src/main/resources/META-INF/maven/site.vm?view=markup#l1055].
> Swap {{class="row span12"}} to {{class="pull-right"}}.
--
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] (MSKINS-72) Add copyright notice position option
[
https://jira.codehaus.org/browse/MSKINS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-72:
-
Attachment: MSKINS-72.patch
> Add copyright notice position option
>
>
> Key: MSKINS-72
> URL: https://jira.codehaus.org/browse/MSKINS-72
> Project: Maven Skins
> Issue Type: New Feature
> Components: Fluido Skin
>Affects Versions: fluido-1.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: fluido-1.3.1
>
> Attachments: MSKINS-72.patch, mylyn-context.zip
>
>
> The default skin has the copyright notice on the right-hand side of the
> screen. This has unfortunately changed in fluido skin.
> Add a {{}} element to site.xml/custom/fluidoSkin with left
> or right as values.
> IMHO default should be as in default skin.
> If current state will be retained, the right position has to be added to
> [this
> line|http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/src/main/resources/META-INF/maven/site.vm?view=markup#l1055].
> Swap {{class="row span12"}} to {{class="pull-right"}}.
--
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] (MSKINS-72) Add copyright notice position option
[
https://jira.codehaus.org/browse/MSKINS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-72:
-
Assignee: Olivier Lamy (was: Michael Osipov)
Remaining Estimate: 0 minutes
Original Estimate: 0 minutes
> Add copyright notice position option
>
>
> Key: MSKINS-72
> URL: https://jira.codehaus.org/browse/MSKINS-72
> Project: Maven Skins
> Issue Type: New Feature
> Components: Fluido Skin
>Affects Versions: fluido-1.3.0
>Reporter: Michael Osipov
>Assignee: Olivier Lamy
> Fix For: fluido-1.3.1
>
> Attachments: MSKINS-72.patch, mylyn-context.zip
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> The default skin has the copyright notice on the right-hand side of the
> screen. This has unfortunately changed in fluido skin.
> Add a {{}} element to site.xml/custom/fluidoSkin with left
> or right as values.
> IMHO default should be as in default skin.
> If current state will be retained, the right position has to be added to
> [this
> line|http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/src/main/resources/META-INF/maven/site.vm?view=markup#l1055].
> Swap {{class="row span12"}} to {{class="pull-right"}}.
--
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] (MSKINS-72) Add copyright notice position option
[
https://jira.codehaus.org/browse/MSKINS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325305#comment-325305
]
Michael Osipov edited comment on MSKINS-72 at 5/20/13 9:28 AM:
---
I am not able to apply the patch myself: 403 Forbidden. Please apply patch
until ACL has been clarified.
was (Author: michael-o):
I am not able to apply the patch myself: 403 Forbidden. Please apply patch
unless ACL has been clarified.
> Add copyright notice position option
>
>
> Key: MSKINS-72
> URL: https://jira.codehaus.org/browse/MSKINS-72
> Project: Maven Skins
> Issue Type: New Feature
> Components: Fluido Skin
>Affects Versions: fluido-1.3.0
>Reporter: Michael Osipov
>Assignee: Olivier Lamy
> Fix For: fluido-1.3.1
>
> Attachments: MSKINS-72.patch, mylyn-context.zip
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> The default skin has the copyright notice on the right-hand side of the
> screen. This has unfortunately changed in fluido skin.
> Add a {{}} element to site.xml/custom/fluidoSkin with left
> or right as values.
> IMHO default should be as in default skin.
> If current state will be retained, the right position has to be added to
> [this
> line|http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.3.0/src/main/resources/META-INF/maven/site.vm?view=markup#l1055].
> Swap {{class="row span12"}} to {{class="pull-right"}}.
--
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-838) Creating a branch from a tag does not work
[ https://jira.codehaus.org/browse/MRELEASE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325307#comment-325307 ] DK commented on MRELEASE-838: - The following command: mvn release:branch -DupdateBranchVersions=true -DupdateVersionsToSnapshot=false -DupdateDependencies=false -DupdateWorkingCopyVersions=false -DsuppressCommitBeforeBranch=true -DbranchName=MyBranch Results in: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.1:branch (default-cli) on project myproject: Cannot perform a remote tag or branch without committing the working copy first. -> [Help 1] [ERROR] But I cannot/should not commit to the tag > Creating a branch from a tag does not work > -- > > Key: MRELEASE-838 > URL: https://jira.codehaus.org/browse/MRELEASE-838 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.4.1 >Reporter: DK >Priority: Blocker > > I'm trying to use the following command to create a branch from an SVN tag: > mvn release:branch -DupdateBranchVersions=true > -DupdateVersionsToSnapshot=false -DupdateWorkingCopyVersions=false > -DbranchName=MyBranch > However, it makes commits to the tag which it shouldn't and also updates the > version and dependencies in the branch pom to the latest SNAPSHOT. > I also tried: > mvn release:branch -DupdateBranchVersions=true > -DupdateVersionsToSnapshot=false -DupdateDependencies=false > -DupdateWorkingCopyVersions=false -DsuppressCommitBeforeBranch=true > -DbranchName=MyBranch > And this fails with: > [ERROR] Error resolving version for plugin 'maven-release-plugin:2.4.1' from > the repositories [local (/root/.m2/repository), central > (http://nexus.forge.avaya.com/content/groups/public), ace_special > (http://nexus.forge.avaya.com/content/repositories/ace_special)]: Plugin not > found in any plugin repository -> [Help 1] > I think this is a pretty major bug. -- 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-838) Creating a branch from a tag does not work
DK created MRELEASE-838: --- Summary: Creating a branch from a tag does not work Key: MRELEASE-838 URL: https://jira.codehaus.org/browse/MRELEASE-838 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.4.1 Reporter: DK Priority: Blocker I'm trying to use the following command to create a branch from an SVN tag: mvn release:branch -DupdateBranchVersions=true -DupdateVersionsToSnapshot=false -DupdateWorkingCopyVersions=false -DbranchName=MyBranch However, it makes commits to the tag which it shouldn't and also updates the version and dependencies in the branch pom to the latest SNAPSHOT. I also tried: mvn release:branch -DupdateBranchVersions=true -DupdateVersionsToSnapshot=false -DupdateDependencies=false -DupdateWorkingCopyVersions=false -DsuppressCommitBeforeBranch=true -DbranchName=MyBranch And this fails with: [ERROR] Error resolving version for plugin 'maven-release-plugin:2.4.1' from the repositories [local (/root/.m2/repository), central (http://nexus.forge.avaya.com/content/groups/public), ace_special (http://nexus.forge.avaya.com/content/repositories/ace_special)]: Plugin not found in any plugin repository -> [Help 1] I think this is a pretty major bug. -- 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-838) Creating a branch from a tag does not work
[ https://jira.codehaus.org/browse/MRELEASE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325306#comment-325306 ] DK commented on MRELEASE-838: - Sorry you can ignore the second command i tried > Creating a branch from a tag does not work > -- > > Key: MRELEASE-838 > URL: https://jira.codehaus.org/browse/MRELEASE-838 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.4.1 >Reporter: DK >Priority: Blocker > > I'm trying to use the following command to create a branch from an SVN tag: > mvn release:branch -DupdateBranchVersions=true > -DupdateVersionsToSnapshot=false -DupdateWorkingCopyVersions=false > -DbranchName=MyBranch > However, it makes commits to the tag which it shouldn't and also updates the > version and dependencies in the branch pom to the latest SNAPSHOT. > I also tried: > mvn release:branch -DupdateBranchVersions=true > -DupdateVersionsToSnapshot=false -DupdateDependencies=false > -DupdateWorkingCopyVersions=false -DsuppressCommitBeforeBranch=true > -DbranchName=MyBranch > And this fails with: > [ERROR] Error resolving version for plugin 'maven-release-plugin:2.4.1' from > the repositories [local (/root/.m2/repository), central > (http://nexus.forge.avaya.com/content/groups/public), ace_special > (http://nexus.forge.avaya.com/content/repositories/ace_special)]: Plugin not > found in any plugin repository -> [Help 1] > I think this is a pretty major bug. -- 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-838) Creating a branch from a tag does not work
[ https://jira.codehaus.org/browse/MRELEASE-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DK closed MRELEASE-838. --- Resolution: Not A Bug Fix Version/s: 2.4.1 > Creating a branch from a tag does not work > -- > > Key: MRELEASE-838 > URL: https://jira.codehaus.org/browse/MRELEASE-838 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.4.1 >Reporter: DK >Priority: Blocker > Fix For: 2.4.1 > > > I'm trying to use the following command to create a branch from an SVN tag: > mvn release:branch -DupdateBranchVersions=true > -DupdateVersionsToSnapshot=false -DupdateWorkingCopyVersions=false > -DbranchName=MyBranch > However, it makes commits to the tag which it shouldn't and also updates the > version and dependencies in the branch pom to the latest SNAPSHOT. > I also tried: > mvn release:branch -DupdateBranchVersions=true > -DupdateVersionsToSnapshot=false -DupdateDependencies=false > -DupdateWorkingCopyVersions=false -DsuppressCommitBeforeBranch=true > -DbranchName=MyBranch > And this fails with: > [ERROR] Error resolving version for plugin 'maven-release-plugin:2.4.1' from > the repositories [local (/root/.m2/repository), central > (http://nexus.forge.avaya.com/content/groups/public), ace_special > (http://nexus.forge.avaya.com/content/repositories/ace_special)]: Plugin not > found in any plugin repository -> [Help 1] > I think this is a pretty major bug. -- 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] [Created] (MPOM-43) Prevent dependency with too recent bytecode from creeping in unnoticed
Hervé Boutemy created MPOM-43: - Summary: Prevent dependency with too recent bytecode from creeping in unnoticed Key: MPOM-43 URL: https://issues.apache.org/jira/browse/MPOM-43 Project: Maven POMs Issue Type: Improvement Components: maven Affects Versions: MAVEN-23 Reporter: Hervé Boutemy As a followup to http://www.mail-archive.com/dev@maven.apache.org/msg96659.html here's a patch that configures an additional enforcer rule to prevent using dependencies that were compiled with a compiler more recent than the maximum allowed. see https://jira.codehaus.org/browse/MNG-5481 -- 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-5481) Prevent dependency with too recent bytecode from creeping in unnoticed
[ https://jira.codehaus.org/browse/MNG-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-5481. -- Resolution: Fixed Assignee: Herve Boutemy moved to https://issues.apache.org/jira/browse/MPOM-43 > Prevent dependency with too recent bytecode from creeping in unnoticed > -- > > Key: MNG-5481 > URL: https://jira.codehaus.org/browse/MNG-5481 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: POM >Reporter: Baptiste Mathus >Assignee: Herve Boutemy >Priority: Minor > Attachments: MNG-5481.patch > > > As a followup to > http://www.mail-archive.com/dev@maven.apache.org/msg96659.html here's a patch > that configures an additional enforcer rule to prevent using dependencies > that were compiled with a compiler more recent than the maximum allowed. > The proposed patch patches the maven-plugins/pom.xml but if you think this > should go somewhere else, don't hesitate to ask. > Cheers > PS : not perfectly sure this is the right JIRA project, please just tell me > if this should be relocated. -- 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-567) mvn release:prepare fails with missing artifacts when running assembly
[
https://jira.codehaus.org/browse/MRELEASE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325312#comment-325312
]
Lewis Henderson commented on MRELEASE-567:
--
I think that this is either a similar or the same problem that I have...
I am trying to do a release:prepare (clean verify) and get errors with missing
dependencies that are in the current build. I had the problem with the
maven-dependency-plugin where I was using the 'copy' goal when I should have
been using the 'copy-dependencies' goal. The copy-dependencies goal first looks
in the current reactor, then the local repository and then remote. This is the
same requirement for other 'bundling' type plugins. The 'jarResource's should
be looked up in the same way. This is a show stopper for the release plugin
when using the webstart (or other) bundling plugins.
> mvn release:prepare fails with missing artifacts when running assembly
> --
>
> Key: MRELEASE-567
> URL: https://jira.codehaus.org/browse/MRELEASE-567
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Perforce, jdk1.6.0_07, Maven 2.2.1
>Reporter: Markus Muenkel
>
> The issue has been discussed in the user mailing list, cf.
> http://mail-archives.apache.org/mod_mbox/maven-users/201005.mbox/%3caanlktikxpj792-g1cdzen1r8wefs1456u3duclb40...@mail.gmail.com%3e
> I'm releasing a Maven2 multi-module project. One of the modules is a POM
> project ("assembly project") that uses the maven-assembly-plugin in order to
> build an assembly (zip archive). The artifacts to be assembled are specified
> via dependencies in the POM. They point to modules contained in the same
> multi-module project. The project build is running fine and produces the
> desired results.
> The project structure is as follows:
> commons
> |
> |-- commons.util
> |
> |-- commons.util.test
> |
> |-- commons.distribution
> | |
> | |-- assembly_descriptor.xml
> When running mvn release:prepare on this multi-module project, the build of
> the assembly project commons.distribution fails with the message that the
> dependencies cannot be
> resolved. These dependencies are reported with the version that should be
> released, e.g. 0.0.3. Before running the goal, all dependency versions are
> 0.0.3-SNAPSHOT.
> What seems to happen is that the snapshot version 0.0.3-SNAPSHOT is
> replaced by release version 0.0.3 through the release plugin and consequently
> the assembly plugin tries to resolve the dependencies based on version
> 0.0.3 which however do not yet exist in the repository at that point.
> It was suggested in the mail thread that the reactor should be able to handle
> the dependencies correctly and the following test was proposed:
> 1. mvn versions:set -DnewVersion=0.0.3-reltesting-SNAPSHOT
> 2. mvn clean verify
> 3. mvn versions:revert
> However this test fails in the same manner as described above.
> The issue can be reproduced with any multi-module project of the structure
> T
> |--A
> |--X
> |--...
> where T is a top-level project and A is a child project of packaging type POM
> that assembles module X (and possibly other modules
> as indicated by the ellipsis).
--
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-5477) "malformed POM" warning issued when no version in reporting section
[ https://jira.codehaus.org/browse/MNG-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325314#comment-325314 ] Herve Boutemy commented on MNG-5477: unit test added in [ed1501ec|http://git-wip-us.apache.org/repos/asf/maven/commit/ed1501ec] > "malformed POM" warning issued when no version in reporting section > --- > > Key: MNG-5477 > URL: https://jira.codehaus.org/browse/MNG-5477 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.0.5 > Environment: Ubuntu 12.04 / Oracle JDK 7u17 / Maven 3.0.5 / m-site-p > 3.2 >Reporter: Wolf Geldmacher >Priority: Minor > Fix For: 3.1.0 > > Attachments: mvn-site.zip > > > When "mvn site" is run on the project attached Maven twice complains that > "'reporting.plugins.plugin.version' for > org.apache.maven.plugins:maven-project-info-reports-plugin is missing", while > the documentation on > http://maven.apache.org/plugins/maven-site-plugin/maven-3.html clearly states > that "When used with Maven 3, a report plugin version can be empty (like > build plugins)." > The plugin version actually used seems to be the one specified in the > pluginManagement section of the parent POM, though. -- 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-5477) "malformed POM" warning issued when no version in reporting section
[ https://jira.codehaus.org/browse/MNG-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-5477. -- Resolution: Fixed Fix Version/s: (was: 3.1.0) 3.1.0-alpha-1 Assignee: Herve Boutemy done in [4db66fd0|http://git-wip-us.apache.org/repos/asf/maven/commit/4db66fd0] > "malformed POM" warning issued when no version in reporting section > --- > > Key: MNG-5477 > URL: https://jira.codehaus.org/browse/MNG-5477 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.0.5 > Environment: Ubuntu 12.04 / Oracle JDK 7u17 / Maven 3.0.5 / m-site-p > 3.2 >Reporter: Wolf Geldmacher >Assignee: Herve Boutemy >Priority: Minor > Fix For: 3.1.0-alpha-1 > > Attachments: mvn-site.zip > > > When "mvn site" is run on the project attached Maven twice complains that > "'reporting.plugins.plugin.version' for > org.apache.maven.plugins:maven-project-info-reports-plugin is missing", while > the documentation on > http://maven.apache.org/plugins/maven-site-plugin/maven-3.html clearly states > that "When used with Maven 3, a report plugin version can be empty (like > build plugins)." > The plugin version actually used seems to be the one specified in the > pluginManagement section of the parent POM, though. -- 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
