[jira] (MCHECKSTYLE-180) Multimodule configuration example does not work
[
https://jira.codehaus.org/browse/MCHECKSTYLE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306616#comment-306616
]
Zlika commented on MCHECKSTYLE-180:
---
Thank you for your answer.
So that means that either I have a non reproductible (because no specific
plugin version is declared in the buildtool pom) or I need to duplicate the
pluginManagement section ?
None of these solutions seem right to me.
Multimodule configuration example does not work
---
Key: MCHECKSTYLE-180
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-180
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Maven 3.0.4, Ubuntu 12.04 64bit
Reporter: Zlika
Attachments: test-buildtools.zip
I followed the multimodule example from
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html,
but it does not seem to work.
With the attached test case, when I do mvn verify the build fail. It seems
that Maven wants to download the buildtool module from the local repository
(instead of building it), but it cannot find it.
{noformat}
mvn verify
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] test-parent
[INFO] Build tools
[INFO] test-test
[INFO]
[INFO]
[INFO] Building test-parent 0.1-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-checkstyle-plugin:2.9.1:check (default) @ test-parent ---
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/maven-metadata.xml
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/test-buildtools-0.1-SNAPSHOT.jar
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] test-parent ... FAILURE [3.345s]
[INFO] Build tools ... SKIPPED
[INFO] test-test . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.958s
[INFO] Finished at: Mon Aug 20 14:39:55 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check (default) on
project test-parent: Execution default of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check failed: Plugin
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1 or one of its
dependencies could not be resolved: Could not find artifact
testgroup:test-buildtools:jar:0.1-SNAPSHOT in apache.snapshots
(http://repository.apache.org/snapshots) - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
{noformat}
--
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] (MCHECKSTYLE-180) Multimodule configuration example does not work
[
https://jira.codehaus.org/browse/MCHECKSTYLE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306616#comment-306616
]
Zlika edited comment on MCHECKSTYLE-180 at 8/21/12 1:23 AM:
Thank you for your answer.
So that means that either I have a non reproductible build (because no specific
plugin version is declared in the buildtool pom) or I need to duplicate the
pluginManagement section ?
None of these solutions seem right to me.
was (Author: zlika):
Thank you for your answer.
So that means that either I have a non reproductible (because no specific
plugin version is declared in the buildtool pom) or I need to duplicate the
pluginManagement section ?
None of these solutions seem right to me.
Multimodule configuration example does not work
---
Key: MCHECKSTYLE-180
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-180
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Maven 3.0.4, Ubuntu 12.04 64bit
Reporter: Zlika
Attachments: test-buildtools.zip
I followed the multimodule example from
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html,
but it does not seem to work.
With the attached test case, when I do mvn verify the build fail. It seems
that Maven wants to download the buildtool module from the local repository
(instead of building it), but it cannot find it.
{noformat}
mvn verify
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] test-parent
[INFO] Build tools
[INFO] test-test
[INFO]
[INFO]
[INFO] Building test-parent 0.1-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-checkstyle-plugin:2.9.1:check (default) @ test-parent ---
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/maven-metadata.xml
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/test-buildtools-0.1-SNAPSHOT.jar
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] test-parent ... FAILURE [3.345s]
[INFO] Build tools ... SKIPPED
[INFO] test-test . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.958s
[INFO] Finished at: Mon Aug 20 14:39:55 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check (default) on
project test-parent: Execution default of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check failed: Plugin
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1 or one of its
dependencies could not be resolved: Could not find artifact
testgroup:test-buildtools:jar:0.1-SNAPSHOT in apache.snapshots
(http://repository.apache.org/snapshots) - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
{noformat}
--
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] (MDEP-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MDEP-368:
-
Assignee: Olivier Lamy
Configure plexus-archiver to use java.io.File methods to set permissions when
available.
Key: MDEP-368
URL: https://jira.codehaus.org/browse/MDEP-368
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Affects Versions: 2.5
Reporter: Tim Moore
Assignee: Olivier Lamy
Attachments: useJvmChmod.patch
We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
that it slowed down significantly. Our build process involves unpacking
several large zip files, and profiling the build showed us that the extra
time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
executing a {{chmod}} process for each file in the archive.
We tracked this change to an update of the Plexus Archiver dependency from
2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
http://svn.apache.org/viewvc?view=revisionrevision=1292983
Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
and {{setExecutable}} methods on {{java.io.File}} instead of executing
{{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
using reflection when they are available, falling back on executing {{chmod}}
when they are not, so it remains backwards compatible with Java 5.
This configuration is disabled by default, but can be configured via Plexus.
The attached patch to Maven Dependency Plugin sets the archiver components to
use the JVM implementation when available.
The patch doesn't include tests, since the behavior is dependent on the Java
version used, but when applied all of the existing tests pass in Java 6.
Credit for the investigation and the patch is due to Vincent Choy
(vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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] (MCHECKSTYLE-180) Multimodule configuration example does not work
[
https://jira.codehaus.org/browse/MCHECKSTYLE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306616#comment-306616
]
Zlika edited comment on MCHECKSTYLE-180 at 8/21/12 2:26 AM:
Thank you for your answer.
So that means that either I have a non reproductible build (because no specific
plugin version is declared in the buildtool pom) or I need to duplicate the
pluginManagement section of the parent ?
None of these solutions seems right to me.
was (Author: zlika):
Thank you for your answer.
So that means that either I have a non reproductible build (because no specific
plugin version is declared in the buildtool pom) or I need to duplicate the
pluginManagement section ?
None of these solutions seem right to me.
Multimodule configuration example does not work
---
Key: MCHECKSTYLE-180
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-180
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Maven 3.0.4, Ubuntu 12.04 64bit
Reporter: Zlika
Attachments: test-buildtools.zip
I followed the multimodule example from
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html,
but it does not seem to work.
With the attached test case, when I do mvn verify the build fail. It seems
that Maven wants to download the buildtool module from the local repository
(instead of building it), but it cannot find it.
{noformat}
mvn verify
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] test-parent
[INFO] Build tools
[INFO] test-test
[INFO]
[INFO]
[INFO] Building test-parent 0.1-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-checkstyle-plugin:2.9.1:check (default) @ test-parent ---
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/maven-metadata.xml
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/test-buildtools-0.1-SNAPSHOT.jar
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] test-parent ... FAILURE [3.345s]
[INFO] Build tools ... SKIPPED
[INFO] test-test . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.958s
[INFO] Finished at: Mon Aug 20 14:39:55 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check (default) on
project test-parent: Execution default of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check failed: Plugin
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1 or one of its
dependencies could not be resolved: Could not find artifact
testgroup:test-buildtools:jar:0.1-SNAPSHOT in apache.snapshots
(http://repository.apache.org/snapshots) - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
{noformat}
--
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] (MDEP-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306619#comment-306619
]
Olivier Lamy commented on MDEP-368:
---
Your patch activate this by default, this will generate a ton of warnings for
1.5 users.
I prefer we use a new configuration field as I did for assembly plugin to
activate this.
I will do that.
Configure plexus-archiver to use java.io.File methods to set permissions when
available.
Key: MDEP-368
URL: https://jira.codehaus.org/browse/MDEP-368
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Affects Versions: 2.5
Reporter: Tim Moore
Assignee: Olivier Lamy
Attachments: useJvmChmod.patch
We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
that it slowed down significantly. Our build process involves unpacking
several large zip files, and profiling the build showed us that the extra
time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
executing a {{chmod}} process for each file in the archive.
We tracked this change to an update of the Plexus Archiver dependency from
2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
http://svn.apache.org/viewvc?view=revisionrevision=1292983
Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
and {{setExecutable}} methods on {{java.io.File}} instead of executing
{{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
using reflection when they are available, falling back on executing {{chmod}}
when they are not, so it remains backwards compatible with Java 5.
This configuration is disabled by default, but can be configured via Plexus.
The attached patch to Maven Dependency Plugin sets the archiver components to
use the JVM implementation when available.
The patch doesn't include tests, since the behavior is dependent on the Java
version used, but when applied all of the existing tests pass in Java 6.
Credit for the investigation and the patch is due to Vincent Choy
(vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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] (MDEP-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MDEP-368.
-
Resolution: Fixed
Fix Version/s: 2.5.1
Configure plexus-archiver to use java.io.File methods to set permissions when
available.
Key: MDEP-368
URL: https://jira.codehaus.org/browse/MDEP-368
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Affects Versions: 2.5
Reporter: Tim Moore
Assignee: Olivier Lamy
Fix For: 2.5.1
Attachments: useJvmChmod.patch
We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
that it slowed down significantly. Our build process involves unpacking
several large zip files, and profiling the build showed us that the extra
time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
executing a {{chmod}} process for each file in the archive.
We tracked this change to an update of the Plexus Archiver dependency from
2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
http://svn.apache.org/viewvc?view=revisionrevision=1292983
Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
and {{setExecutable}} methods on {{java.io.File}} instead of executing
{{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
using reflection when they are available, falling back on executing {{chmod}}
when they are not, so it remains backwards compatible with Java 5.
This configuration is disabled by default, but can be configured via Plexus.
The attached patch to Maven Dependency Plugin sets the archiver components to
use the JVM implementation when available.
The patch doesn't include tests, since the behavior is dependent on the Java
version used, but when applied all of the existing tests pass in Java 6.
Credit for the investigation and the patch is due to Vincent Choy
(vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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] (MDEP-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306620#comment-306620
]
Olivier Lamy commented on MDEP-368:
---
fixed and snapshot deployed.
you can now use
useJvmChmodtrue/useJvmChmod
Configure plexus-archiver to use java.io.File methods to set permissions when
available.
Key: MDEP-368
URL: https://jira.codehaus.org/browse/MDEP-368
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Affects Versions: 2.5
Reporter: Tim Moore
Assignee: Olivier Lamy
Fix For: 2.5.1
Attachments: useJvmChmod.patch
We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
that it slowed down significantly. Our build process involves unpacking
several large zip files, and profiling the build showed us that the extra
time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
executing a {{chmod}} process for each file in the archive.
We tracked this change to an update of the Plexus Archiver dependency from
2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
http://svn.apache.org/viewvc?view=revisionrevision=1292983
Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
and {{setExecutable}} methods on {{java.io.File}} instead of executing
{{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
using reflection when they are available, falling back on executing {{chmod}}
when they are not, so it remains backwards compatible with Java 5.
This configuration is disabled by default, but can be configured via Plexus.
The attached patch to Maven Dependency Plugin sets the archiver components to
use the JVM implementation when available.
The patch doesn't include tests, since the behavior is dependent on the Java
version used, but when applied all of the existing tests pass in Java 6.
Credit for the investigation and the patch is due to Vincent Choy
(vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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] (MDEP-368) Configure plexus-archiver to use java.io.File methods to set permissions when available.
[
https://jira.codehaus.org/browse/MDEP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306620#comment-306620
]
Olivier Lamy edited comment on MDEP-368 at 8/21/12 2:47 AM:
fixed and snapshot deployed (next release will 2.5.1 so use 2.5.1-SNAPSHOT).
you can now use
useJvmChmodtrue/useJvmChmod
was (Author: olamy):
fixed and snapshot deployed.
you can now use
useJvmChmodtrue/useJvmChmod
Configure plexus-archiver to use java.io.File methods to set permissions when
available.
Key: MDEP-368
URL: https://jira.codehaus.org/browse/MDEP-368
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: unpack, unpack-dependencies
Affects Versions: 2.5
Reporter: Tim Moore
Assignee: Olivier Lamy
Fix For: 2.5.1
Attachments: useJvmChmod.patch
We updated from maven-dependency-plugin 2.4 to 2.5 in our build, and found
that it slowed down significantly. Our build process involves unpacking
several large zip files, and profiling the build showed us that the extra
time was spent in Plexus Archiver's {{ArchiveEntryUtils.chmod}}, where it was
executing a {{chmod}} process for each file in the archive.
We tracked this change to an update of the Plexus Archiver dependency from
2.0 to 2.1.1 in version 2.5 of the Maven Dependency Plugin:
http://svn.apache.org/viewvc?view=revisionrevision=1292983
Plexus Archiver can be configured to use the {{setReadable}}, {{setWritable}}
and {{setExecutable}} methods on {{java.io.File}} instead of executing
{{chmod}}. These methods are new in Java 6, but Plexus Archiver invokes them
using reflection when they are available, falling back on executing {{chmod}}
when they are not, so it remains backwards compatible with Java 5.
This configuration is disabled by default, but can be configured via Plexus.
The attached patch to Maven Dependency Plugin sets the archiver components to
use the JVM implementation when available.
The patch doesn't include tests, since the behavior is dependent on the Java
version used, but when applied all of the existing tests pass in Java 6.
Credit for the investigation and the patch is due to Vincent Choy
(vc...@atlassian.com). He asked me to file this issue on his behalf.
--
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] (MNG-5205) Memory leak in StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306624#comment-306624
]
Kristian Rosenvold commented on MNG-5205:
-
The code in question is an extreme hotspot in maven, but the caching in
question could probably be made a lot smarter (and more technically correct to
avoid the leak).
There is a duplication in the codebase, this class exists both a deprecated and
a non-deprecated version.
At a minimum, it seems like it'd make sense to cache class-field mapping at
the level isQualifiedForInterpolation(field, method), simply because it would
speed things up quite noticeably. I'm studying the overall context of this
algorithm to see if there's any higher-level simplifications to be made.
Memory leak in StringSearchModelInterpolator
Key: MNG-5205
URL: https://jira.codehaus.org/browse/MNG-5205
Project: Maven 2 3
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0.3
Reporter: Jesse Glick
Priority: Minor
Fix For: 3.0.5
Attachments: x.diff
{{StringSearchModelInterpolator}} abuses {{WeakHashMap}}; the {{Field}}
values of {{fieldsByClass}} hold hard references to the {{Class}} keys,
making it useless. Thus if you passed any {{Class}} to it, that class and its
{{ClassLoader}} and the transitive static graph therefrom would never be
collectible.
Anyway a cache is unnecessary, since {{Class}} does its own caching of fields!
Also removing the ill-conceived {{fieldIsPrimitiveByClass}} - not a memory
leak, but likely unnecessary complication.
The class is deprecated anyway, but just in case it is used by someone it
should be fixed.
--
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] (MDEP-98) The source must not be a directory
[
https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306631#comment-306631
]
Michal Rembiszewski commented on MDEP-98:
-
I had this issue also with sonar:sonar. There is a simple workaround which
could be applicable for some other scenarios as well. The problem is unpack
will attempt to use folder as its source only if package was not executed for
this module as part of the build.
So in my case the workaround was to run mvn package sonar:sonar instead of
mvn sonar:sonar. The former does certain things twice so it's less effective,
but when reactor detects package was performed, it will unpack dependencies
from jar instead of going for the folder. Probably the workaround can be
improved through explicit package execution.
The source must not be a directory
--
Key: MDEP-98
URL: https://jira.codehaus.org/browse/MDEP-98
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack, unpack-dependencies
Affects Versions: 2.0-alpha-4
Environment: Windows XP Professional SP2
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
Reporter: Pablo Muñiz
Assignee: Brian Fox
Attachments: MDEP-98-ITs.patch,
mdep98-testcase-parent-with-surefire.zip, mdep98-testcase-parent.zip
Using maven-dependency-plugin in a multimodule project inside a module wich
has a dependency with another module in the same project the next error
ocurrs :
{noformat}org.codehaus.plexus.archiver.ArchiverException: The source must not
be a directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232)
at
org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error unpacking file:
c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to:
c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes
org.codehaus.plexus.archiver.ArchiverException: The source must not be a
directory.{noformat}
Project structure is as follows:
plataforma
- platform-core
- platform-bundle
- platform-bundle-jar
- platform-bundle-src
and the error happens on executing any goal from parent pom.
maven-dependency-plugin seems to receive a reference to target/classes
directory for platform-core dependency instead of the URL to my local
repository where platform-core is located.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] (MDEP-98) The source must not be a directory
[
https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306632#comment-306632
]
Samuel Langlois commented on MDEP-98:
-
For Sonar, the official workaround is to use the sonar.phase parameter,
asking Sonar to run the build up to a certain phase:
{code}
mvn sonar:sonar -Dsonar.phase=package
{code}
This is probably quite similar to the previous comment, and of course it runs
the tests twice.
(I must confess I sometimes move the goal that packages from the {{package}}
phase to the {{process-test-classes}} phase, so that I only have to build up to
that phase, avoiding the {{test}} phase. Shame on me...)
The source must not be a directory
--
Key: MDEP-98
URL: https://jira.codehaus.org/browse/MDEP-98
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack, unpack-dependencies
Affects Versions: 2.0-alpha-4
Environment: Windows XP Professional SP2
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
Reporter: Pablo Muñiz
Assignee: Brian Fox
Attachments: MDEP-98-ITs.patch,
mdep98-testcase-parent-with-surefire.zip, mdep98-testcase-parent.zip
Using maven-dependency-plugin in a multimodule project inside a module wich
has a dependency with another module in the same project the next error
ocurrs :
{noformat}org.codehaus.plexus.archiver.ArchiverException: The source must not
be a directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232)
at
org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error unpacking file:
c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to:
c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes
org.codehaus.plexus.archiver.ArchiverException: The source must not be a
directory.{noformat}
Project structure is as follows:
plataforma
- platform-core
- platform-bundle
- platform-bundle-jar
- platform-bundle-src
and the error happens on executing any goal from parent pom.
maven-dependency-plugin seems to receive a reference to target/classes
directory for platform-core dependency instead of the URL to my local
repository where platform-core is located.
--
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-511) release:prepare Error parsing version, cannot determine next version: Unable to parse the version string when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306634#comment-306634
]
Michal Minicki commented on MRELEASE-511:
-
@Robert, I have a minor request. I know we shouldn't use unsupported versioning
scheme but unfortunately we do.
The version cannot be parsed in such case (obviously), so release version stays
without default hinted. But maybe you could hint the release version by
stripping -SNAPSHOT if it is present? It feels like a trivial thing to do
without major refactoring. I'm mean for the first question alone (What is the
release version for ...)
{code}
[INFO] Checking dependencies and plugins for snapshots ...
[WARNING] Error parsing version, cannot determine next version: Unable to parse
the version string: R.22.9-SNAPSHOT
What is the release version for Windykacja MVNO?
(pl.cyfrowypolsat:windykacja-mvno) 1.0: : R.22.9
What is SCM release tag or label for Windykacja MVNO?
(pl.cyfrowypolsat:windykacja-mvno) windykacja-mvno-R.22.9: :
[WARNING] Error parsing version, cannot determine next version: Unable to parse
the version string: R.22.9-SNAPSHOT
What is the new development version for Windykacja MVNO?
(pl.cyfrowypolsat:windykacja-mvno) 1.1-SNAPSHOT: : R.22.10-SNAPSHOT
{code}
release:prepare Error parsing version, cannot determine next version: Unable
to parse the version string when running in batch mode.
--
Key: MRELEASE-511
URL: https://jira.codehaus.org/browse/MRELEASE-511
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9
Environment: Win Xp Pro 64bit Java 1.6
Reporter: David Cloutier
Assignee: Robert Scholte
Priority: Critical
Attachments: patch_release_version_patterns.txt
When I try to run release:prepare in batch mode, I get the error below (can't
parse version string) even though I supply the version number by argument. If
I do the same thing with the same versions in interactive mode, it works fine.
Here is the output:
{noformat}
C:\workspaces\head\MyClientmvn -B -e -Dresume=false -Dtag=PPX
-DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
release:perform
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
[INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
[INFO]
Downloading:
http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
Downloading:
http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases-local
(http://myrepo.int.mycie.com/artifactory/libs-releases-local)
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository central (http://repo1.maven.org/maven2)
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C cvs -z3 -f -t -d
:pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d
[INFO] Working directory: C:\workspaces\head\MyClient
[INFO] Checking dependencies and plugins for snapshots ...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing version, cannot determine next version: Unable to parse
the version string: MYB_200909-SNAPSHOT
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
version, cannot determine next version: Unable to parse the version string:
MYB_200909-SNAPSHOT
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
[jira] (MDEP-369) fails :get using remoteRepositories and maven3
Alexander Kudrevatykh created MDEP-369: -- Summary: fails :get using remoteRepositories and maven3 Key: MDEP-369 URL: https://jira.codehaus.org/browse/MDEP-369 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: get Affects Versions: 2.5, 2.4 Environment: maven3.0.5 windows7 jdk1.7.0_01 Reporter: Alexander Kudrevatykh When I type mvn org.apache.maven.plugins:maven-dependency-plugin:2.5:get -DremoteRepositories=url ... plugin fails to download artifact from remote repository. When using repoId and repoUrl properties or maven 2.2.1 all works fine. -- 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] (MNG-5333) Support expressions for plugin parameters
Mickael Istria created MNG-5333:
---
Summary: Support expressions for plugin parameters
Key: MNG-5333
URL: https://jira.codehaus.org/browse/MNG-5333
Project: Maven 2 3
Issue Type: Wish
Environment: mistria@mistria--rh:~$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /home/mistria/apps/apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.2.0-29-generic, arch: amd64, family: unix
Reporter: Mickael Istria
Use-case:
I want to give as input of my surefire-plugin
configuration
skip${skipTests} || ${skipDownloadRuntimes}/skip
configuration
This won't work because the expressions are not evaluated. Boolean arguments in
plugin are set to something like Boolean.parseBoolean, which is quite limited.
Instead, we could think of introducing an expression language, such as Groovy,
that would allow expressions as parameters for plugins.
Then let's say skipTests=false and skipDownloadRuntimes=true, Maven would first
replace ${skipTests} || ${skipDownloadRuntimes} by false || true and then
this evaluator would evaluate that to false, and skip will receive the value
false.
This would for sure make maven less verbose in some cases.
--
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] (MASSEMBLY-625) Allow props to be defined in configuration
Benson Margulies created MASSEMBLY-625: -- Summary: Allow props to be defined in configuration Key: MASSEMBLY-625 URL: https://jira.codehaus.org/browse/MASSEMBLY-625 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Benson Margulies I find myself wanting to pump out six artifacts that differ only in the classifier of one artifact to be unpacked inside them. It seems that I will need six copies of my descriptor with different include specs in a dependency set to achieve this. How sad. Happier would be if I could have properties in the configuration so that I could have six executions against one descriptor file. I guess I could use something in generate-resources to generate these descriptors from a template. Uck. -- 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-511) release:prepare Error parsing version, cannot determine next version: Unable to parse the version string when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=30#comment-30
]
Robert Scholte commented on MRELEASE-511:
-
With the refactoring (only on my local machine) the suggestion for the
release-version should already be fixed.
release:prepare Error parsing version, cannot determine next version: Unable
to parse the version string when running in batch mode.
--
Key: MRELEASE-511
URL: https://jira.codehaus.org/browse/MRELEASE-511
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9
Environment: Win Xp Pro 64bit Java 1.6
Reporter: David Cloutier
Assignee: Robert Scholte
Priority: Critical
Attachments: patch_release_version_patterns.txt
When I try to run release:prepare in batch mode, I get the error below (can't
parse version string) even though I supply the version number by argument. If
I do the same thing with the same versions in interactive mode, it works fine.
Here is the output:
{noformat}
C:\workspaces\head\MyClientmvn -B -e -Dresume=false -Dtag=PPX
-DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
release:perform
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
[INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
[INFO]
Downloading:
http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
Downloading:
http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases-local
(http://myrepo.int.mycie.com/artifactory/libs-releases-local)
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository central (http://repo1.maven.org/maven2)
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C cvs -z3 -f -t -d
:pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d
[INFO] Working directory: C:\workspaces\head\MyClient
[INFO] Checking dependencies and plugins for snapshots ...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing version, cannot determine next version: Unable to parse
the version string: MYB_200909-SNAPSHOT
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
version, cannot determine next version: Unable to parse the version string:
MYB_200909-SNAPSHOT
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
[jira] (MENFORCER-138) Rule to ban all transitive dependencies
[ https://jira.codehaus.org/browse/MENFORCER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306670#comment-306670 ] Jakub Senko commented on MENFORCER-138: --- Hi, I have created crude implementation of this rule. Rule will fail the build if it detects any transitive dependencies. I have also added an option to exclude certain artifacts from being checked. This works the same as exclude and include here: http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html I have also added an option to write a custom message to user if the rule fails. Code is here https://github.com/jsenko/enforcer-rule, but it needs some polishing. I would welcome any suggestions. Rule to ban all transitive dependencies --- Key: MENFORCER-138 URL: https://jira.codehaus.org/browse/MENFORCER-138 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Reporter: Paul Gier In some projects it's necessary (or at least desirable) to have all dependencies specified in pom. It would be nice to have an enforcer rule that would ban all transitive dependencies so that the user could either add the transitive dependency directly to the pom (if it's actually needed), or exclude the dependency. The rule should also have an option to ignore certain transitive dependencies, possibly using a similar syntax to other rules. -- 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] (MNG-3472) configuration possibilities to limit size of local repository
[ https://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306674#comment-306674 ] Eric Dalquist commented on MNG-3472: It is unfortunate that this issue is marked as won't-fix. We run into this problem all the time and are starting to feel lots of pain around managing local repositories. Having some way to: * Purge all but the X newest snapshots of a version * Purge snapshots where a release exists in the local repo Is really critical, for now we'll be doing this via scripts which I'll try to post back here but of course the danger is the local repository meta data may be left in an invalid state since we'll just be deleting files. configuration possibilities to limit size of local repository - Key: MNG-3472 URL: https://jira.codehaus.org/browse/MNG-3472 Project: Maven 2 3 Issue Type: Improvement Components: Settings Affects Versions: 2.0.8 Reporter: manuel aldana it would be great to make repository-size configurable, for instance by setting the maximum number of downloads of a snapshot-version to be kept. thus the explosion of local repository size can be reduced. especially when you are working with many in-house multi-module projects which are marked as snapshots before released , can increase repository size significantly. see mailing-list discussion: http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.html -- 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] (MCHECKSTYLE-180) Multimodule configuration example does not work
[
https://jira.codehaus.org/browse/MCHECKSTYLE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306677#comment-306677
]
Dennis Lundberg commented on MCHECKSTYLE-180:
-
I don't understand what you are saying.
You only need to do one thing to get this to work:
- remove the parent element from your test-buildtools pom.xml
How does that make your build non-reproducible?
Multimodule configuration example does not work
---
Key: MCHECKSTYLE-180
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-180
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Maven 3.0.4, Ubuntu 12.04 64bit
Reporter: Zlika
Attachments: test-buildtools.zip
I followed the multimodule example from
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html,
but it does not seem to work.
With the attached test case, when I do mvn verify the build fail. It seems
that Maven wants to download the buildtool module from the local repository
(instead of building it), but it cannot find it.
{noformat}
mvn verify
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] test-parent
[INFO] Build tools
[INFO] test-test
[INFO]
[INFO]
[INFO] Building test-parent 0.1-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-checkstyle-plugin:2.9.1:check (default) @ test-parent ---
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/maven-metadata.xml
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/test-buildtools-0.1-SNAPSHOT.jar
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] test-parent ... FAILURE [3.345s]
[INFO] Build tools ... SKIPPED
[INFO] test-test . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.958s
[INFO] Finished at: Mon Aug 20 14:39:55 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check (default) on
project test-parent: Execution default of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check failed: Plugin
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1 or one of its
dependencies could not be resolved: Could not find artifact
testgroup:test-buildtools:jar:0.1-SNAPSHOT in apache.snapshots
(http://repository.apache.org/snapshots) - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
{noformat}
--
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] (MNG-5331) JavaFX should be added to compilation classpath
[ https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-5331: --- Issue Type: Wish (was: Bug) JavaFX should be added to compilation classpath --- Key: MNG-5331 URL: https://jira.codehaus.org/browse/MNG-5331 Project: Maven 2 3 Issue Type: Wish Reporter: Konstantin Solomatov Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include them into classpath automatically. -- 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] (MCHECKSTYLE-180) Multimodule configuration example does not work
[
https://jira.codehaus.org/browse/MCHECKSTYLE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306681#comment-306681
]
Zlika commented on MCHECKSTYLE-180:
---
If there is no parent (where I define all the plugin versions), then the
versions of the plugins which will be used to build the buildtool module will
depend on the Maven version (each Maven version comes with a super pom that
defines the default plugin versions). Then the build is not reproductible (in
a sense) because it will depend on the Maven version that will be used.
Moreover, I would have to manage another version number for the buildtool
module (if it has a parent, it inherits its version number), and it would be a
nightmare to manage with the release plugin.
Multimodule configuration example does not work
---
Key: MCHECKSTYLE-180
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-180
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Maven 3.0.4, Ubuntu 12.04 64bit
Reporter: Zlika
Attachments: test-buildtools.zip
I followed the multimodule example from
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html,
but it does not seem to work.
With the attached test case, when I do mvn verify the build fail. It seems
that Maven wants to download the buildtool module from the local repository
(instead of building it), but it cannot find it.
{noformat}
mvn verify
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] test-parent
[INFO] Build tools
[INFO] test-test
[INFO]
[INFO]
[INFO] Building test-parent 0.1-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-checkstyle-plugin:2.9.1:check (default) @ test-parent ---
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/maven-metadata.xml
Downloading:
http://repository.apache.org/snapshots/testgroup/test-buildtools/0.1-SNAPSHOT/test-buildtools-0.1-SNAPSHOT.jar
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] test-parent ... FAILURE [3.345s]
[INFO] Build tools ... SKIPPED
[INFO] test-test . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.958s
[INFO] Finished at: Mon Aug 20 14:39:55 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check (default) on
project test-parent: Execution default of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1:check failed: Plugin
org.apache.maven.plugins:maven-checkstyle-plugin:2.9.1 or one of its
dependencies could not be resolved: Could not find artifact
testgroup:test-buildtools:jar:0.1-SNAPSHOT in apache.snapshots
(http://repository.apache.org/snapshots) - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
{noformat}
--
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] (MSITE-614) site plugin failure when forking a lifecycle
[ https://jira.codehaus.org/browse/MSITE-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306683#comment-306683 ] Dennis Lundberg commented on MSITE-614: --- There were some fairly large changes made to Site Plugin 3.0, so I'm not surprised that a project might work with Site Plugin 2.x but not with 3.x. site plugin failure when forking a lifecycle Key: MSITE-614 URL: https://jira.codehaus.org/browse/MSITE-614 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.0 Reporter: Andreas Pieber Attachments: 5ebbfe13_maven-test.tar.gz If you execute mvn site in the attached test project it fails because of the forked cycles. The test project could therefore not be resolved in the maven plugin. -- 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] (MSKINS-58) upgrade to bootstrap 2.1.0
Olivier Lamy created MSKINS-58: -- Summary: upgrade to bootstrap 2.1.0 Key: MSKINS-58 URL: https://jira.codehaus.org/browse/MSKINS-58 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Reporter: Olivier Lamy -- 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] (MSKINS-58) upgrade to bootstrap 2.1.0
[ https://jira.codehaus.org/browse/MSKINS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MSKINS-58: -- Assignee: Olivier Lamy upgrade to bootstrap 2.1.0 -- Key: MSKINS-58 URL: https://jira.codehaus.org/browse/MSKINS-58 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Reporter: Olivier Lamy Assignee: Olivier Lamy -- 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] (MSKINS-58) upgrade to bootstrap 2.1.0
[ https://jira.codehaus.org/browse/MSKINS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSKINS-58: --- Fix Version/s: fluido-1.3.0 upgrade to bootstrap 2.1.0 -- Key: MSKINS-58 URL: https://jira.codehaus.org/browse/MSKINS-58 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: fluido-1.3.0 -- 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] (MSKINS-58) upgrade to bootstrap 2.1.0
[ https://jira.codehaus.org/browse/MSKINS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSKINS-58. -- Resolution: Fixed fixed. upgrade to bootstrap 2.1.0 -- Key: MSKINS-58 URL: https://jira.codehaus.org/browse/MSKINS-58 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: fluido-1.3.0 -- 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-511) release:prepare Error parsing version, cannot determine next version: Unable to parse the version string when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306711#comment-306711
]
Michal Minicki commented on MRELEASE-511:
-
Great to hear! Thanks. Do you have any idea when it's going to be released?
release:prepare Error parsing version, cannot determine next version: Unable
to parse the version string when running in batch mode.
--
Key: MRELEASE-511
URL: https://jira.codehaus.org/browse/MRELEASE-511
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9
Environment: Win Xp Pro 64bit Java 1.6
Reporter: David Cloutier
Assignee: Robert Scholte
Priority: Critical
Attachments: patch_release_version_patterns.txt
When I try to run release:prepare in batch mode, I get the error below (can't
parse version string) even though I supply the version number by argument. If
I do the same thing with the same versions in interactive mode, it works fine.
Here is the output:
{noformat}
C:\workspaces\head\MyClientmvn -B -e -Dresume=false -Dtag=PPX
-DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
release:perform
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
[INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
[INFO]
Downloading:
http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
Downloading:
http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases-local
(http://myrepo.int.mycie.com/artifactory/libs-releases-local)
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository central (http://repo1.maven.org/maven2)
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C cvs -z3 -f -t -d
:pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d
[INFO] Working directory: C:\workspaces\head\MyClient
[INFO] Checking dependencies and plugins for snapshots ...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing version, cannot determine next version: Unable to parse
the version string: MYB_200909-SNAPSHOT
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
version, cannot determine next version: Unable to parse the version string:
MYB_200909-SNAPSHOT
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
[jira] (MRELEASE-511) release:prepare Error parsing version, cannot determine next version: Unable to parse the version string when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306713#comment-306713
]
Robert Scholte commented on MRELEASE-511:
-
No, currently I'm checking whether tests fail due to invalid assumption or due
to invalid refactoring. Once I think this part is solved, I'll depoly a
SNAPSHOT and will ask for review requests, since this is a very critical part
of the plugin.
There are more issues involved with dependencies (versions of deps with
classifiers are ignored, systemPath is removed) which I'd like to include in
this release.
You'll get a message when I close this issue, which should give you the chance
to verify the fixes.
release:prepare Error parsing version, cannot determine next version: Unable
to parse the version string when running in batch mode.
--
Key: MRELEASE-511
URL: https://jira.codehaus.org/browse/MRELEASE-511
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-9
Environment: Win Xp Pro 64bit Java 1.6
Reporter: David Cloutier
Assignee: Robert Scholte
Priority: Critical
Attachments: patch_release_version_patterns.txt
When I try to run release:prepare in batch mode, I get the error below (can't
parse version string) even though I supply the version number by argument. If
I do the same thing with the same versions in interactive mode, it works fine.
Here is the output:
{noformat}
C:\workspaces\head\MyClientmvn -B -e -Dresume=false -Dtag=PPX
-DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
release:perform
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
[INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
[INFO]
Downloading:
http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
Downloading:
http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository libs-releases-local
(http://myrepo.int.mycie.com/artifactory/libs-releases-local)
Downloading:
http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
[INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
repository central (http://repo1.maven.org/maven2)
[INFO] [release:prepare {execution: default-cli}]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C cvs -z3 -f -t -d
:pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d
[INFO] Working directory: C:\workspaces\head\MyClient
[INFO] Checking dependencies and plugins for snapshots ...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing version, cannot determine next version: Unable to parse
the version string: MYB_200909-SNAPSHOT
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
version, cannot determine next version: Unable to parse the version string:
MYB_200909-SNAPSHOT
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
[jira] (MSKINS-59) Submenu support on dropdowns
[ https://jira.codehaus.org/browse/MSKINS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSKINS-59: --- Fix Version/s: fluido-1.3.0 Assignee: Olivier Lamy Submenu support on dropdowns Key: MSKINS-59 URL: https://jira.codehaus.org/browse/MSKINS-59 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: fluido-1.3.0 -- 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] (MSKINS-59) Submenu support on dropdowns
Olivier Lamy created MSKINS-59: -- Summary: Submenu support on dropdowns Key: MSKINS-59 URL: https://jira.codehaus.org/browse/MSKINS-59 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Reporter: Olivier Lamy -- 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] (MSKINS-59) Submenu support on dropdowns
[ https://jira.codehaus.org/browse/MSKINS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSKINS-59. -- Resolution: Fixed fixed. Submenu support on dropdowns Key: MSKINS-59 URL: https://jira.codehaus.org/browse/MSKINS-59 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: fluido-1.3.0 -- 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
