[jira] [Created] (MASSEMBLY-781) Execution make-assembly fails: user id is too big
Matthew Storer created MASSEMBLY-781:
Summary: Execution make-assembly fails: user id is too big
Key: MASSEMBLY-781
URL: https://issues.apache.org/jira/browse/MASSEMBLY-781
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5.5
Environment: Mac OS X 10.10.4 (Yosemite)
Maven 3.3.3
Reporter: Matthew Storer
While building a multi-module project (X) from the command line using {{mvn
package}}, all defined modules build just fine, but assembling X itself fails
with the following error:
{quote}
[INFO]
[INFO] Building X 1.0
[INFO]
[INFO]
[INFO] --- maven-assembly-plugin:2.5.5:single (make-assembly) @ x ---
[INFO] Reading assembly descriptor: src/assembly/bin-assembly.xml
[INFO] Building tar: /bb/x/target/x-1.0-bin.tar.gz
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] X Common ... SUCCESS [ 3.180 s]
[INFO] Y Model SUCCESS [ 0.269 s]
[INFO] Y Common ... SUCCESS [ 0.279 s]
[INFO] Z Model SUCCESS [ 0.503 s]
[INFO] X Service Model SUCCESS [ 0.139 s]
[INFO] Z .. SUCCESS [ 5.198 s]
[INFO] Y Service .. SUCCESS [ 3.337 s]
[INFO] X Service .. SUCCESS [ 2.186 s]
[INFO] Y User Interface ... SUCCESS [ 1.331 s]
[INFO] X Service User Interface ... SUCCESS [ 1.380 s]
[INFO] Z Utility .. SUCCESS [ 1.316 s]
[INFO] X .. FAILURE [ 0.346 s]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 19.722 s
[INFO] Finished at: 2015-07-23T16:32:34-04:00
[INFO] Final Memory: 53M/279M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (make-assembly) on
project X: Execution make-assembly of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: user id
'1535409742' is too big ( 2097151 ). - [Help 1]
{quote}
Snippet from X multi-module POM that configures maven-assembly-plugin:
{quote}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.5.5/version
configuration
descriptors
descriptorsrc/assembly/bin-assembly.xml/descriptor
descriptorsrc/assembly/src-assembly.xml/descriptor
/descriptors
/configuration
executions
execution
idmake-assembly/id
phasepackage/phase
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
{quote}
Error and stack trace:
{quote}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (make-assembly) on
project X: Execution make-assembly of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: user id
'1535409742' is too big ( 2097151 ). - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (make-assembly) on
project X: Execution make-assembly of goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: user id
'1535409742' is too big ( 2097151 ).
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[jira] [Commented] (SUREFIRE-530) Allow runtime ordering of tests to be specified
[ https://issues.apache.org/jira/browse/SUREFIRE-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14639576#comment-14639576 ] Tibor Digana commented on SUREFIRE-530: --- Assigned to 3.0. We will write the API documentation and my wish is to use script language to come over building customer's artifact and simplify the use. The problem is that plugin configuration is getting too big. Run-order functionality needs some work to be present in configuration. [~Tesseract] you can commit PR with a patch on GitHub and we will use it in 3.0 which will speed up our work. Allow runtime ordering of tests to be specified --- Key: SUREFIRE-530 URL: https://issues.apache.org/jira/browse/SUREFIRE-530 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.4.3 Environment: testNG, Junit Reporter: Nick Pellow Fix For: 3.0 Allow other plugins to specify tests to get run, and preserve the ordering of tests. Currently, a plugin may set the test parameter with a comma separated list of tests to run. However, the order is not preserved. For plugins such as the maven-clover2-plugin, (possibly the maven-reactor-plugin?) that optimize the build/test run, ordering of a tests is a very nice way to ensure the build fails as fast as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-530) Allow runtime ordering of tests to be specified
[ https://issues.apache.org/jira/browse/SUREFIRE-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-530: -- Fix Version/s: 3.0 Allow runtime ordering of tests to be specified --- Key: SUREFIRE-530 URL: https://issues.apache.org/jira/browse/SUREFIRE-530 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.4.3 Environment: testNG, Junit Reporter: Nick Pellow Fix For: 3.0 Allow other plugins to specify tests to get run, and preserve the ordering of tests. Currently, a plugin may set the test parameter with a comma separated list of tests to run. However, the order is not preserved. For plugins such as the maven-clover2-plugin, (possibly the maven-reactor-plugin?) that optimize the build/test run, ordering of a tests is a very nice way to ensure the build fails as fast as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5840) relativePath is used if the groupId and artifactId match irrespective of the version
[ https://issues.apache.org/jira/browse/MNG-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14638928#comment-14638928 ] ASF GitHub Bot commented on MNG-5840: - Github user stephenc commented on the pull request: https://github.com/apache/maven/pull/60#issuecomment-124128970 After no comments against merging this and with @ifedorenko saying go for it I decided to merge... if people object they can revert it out. I am not in love with this fix but it will be fine IMHO for 3.3.6 relativePath is used if the groupId and artifactId match irrespective of the version -- Key: MNG-5840 URL: https://issues.apache.org/jira/browse/MNG-5840 Project: Maven Issue Type: Bug Affects Versions: 3.3.1, 3.3.3 Reporter: Stephen Connolly Assignee: Stephen Connolly Labels: regression Fix For: 3.3.5 Attachments: mng-5840-testcase.tar.gz This is a regression. (In my view a serious one) Works fine with Maven 3.0 through 3.2.5 Fails with 3.3.1 and 3.3.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14638939#comment-14638939
]
ASF GitHub Bot commented on MNG-5805:
-
Github user atanasenko closed the pull request at:
https://github.com/apache/maven/pull/59
Custom packaging types: configuring DefaultLifecycleMapping mojo executions
---
Key: MNG-5805
URL: https://issues.apache.org/jira/browse/MNG-5805
Project: Maven
Issue Type: Improvement
Components: Plugins and Lifecycle
Reporter: Anton Tanasenko
Assignee: Jason van Zyl
Priority: Minor
Fix For: 3.3.5
Currently, DefaultLifecycleMapping does not support mapping phases to goals
with a custom configuration (see
maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
impossible to bind, say, an assembly plugin to 'package' phase within a
custom packaging type, since assembly plugin requires a meaningful
configuration to be set.
At my job, we have a number of poms, each serving a purpose of defining a
lifecycle for a particular type of project (there's one for jar, a couple for
wars and several more for other types of deployable artifacts).
Now that I somewhat understand maven's lifecycle, It seems natural to convert
such poms to custom packaging types, leaving only a single parent with global
config and pluginManagement. But it is currently impossible, since we are
using mostly standard plugins (only occasional dedicated ones) to configure
projects' lifecycles.
I did some digging around and put together a relatively straightforward
change to maven-core:
https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
It both introduces support for specifying configuration and dependencies for
mojo executions:
{code:xml}
install
mojos
mojo
goalorg.apache.maven.plugins:maven-install-plugin:2.4:install/goal
configuration.../configuration
dependencies.../dependencies
/mojo
mojo
...
/mojo
/mojos
/install
{code}
as well as retains support for existing mapping syntax:
{code:xml}
installorg.apache.maven.plugins:maven-install-plugin:2.4:install,
.../install
{code}
I will put together some its (as well as make sure that existing are running
ok) and create a pull request for both. Also, there are a couple of changes
that break API in org/apache/maven/lifecycle/Lifecycle.java and
org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
mantain compatibility in those two?
ITS:
https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5840) relativePath is used if the groupId and artifactId match irrespective of the version
[ https://issues.apache.org/jira/browse/MNG-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14638926#comment-14638926 ] ASF GitHub Bot commented on MNG-5840: - Github user asfgit closed the pull request at: https://github.com/apache/maven/pull/60 relativePath is used if the groupId and artifactId match irrespective of the version -- Key: MNG-5840 URL: https://issues.apache.org/jira/browse/MNG-5840 Project: Maven Issue Type: Bug Affects Versions: 3.3.1, 3.3.3 Reporter: Stephen Connolly Assignee: Stephen Connolly Labels: regression Fix For: 3.3.5 Attachments: mng-5840-testcase.tar.gz This is a regression. (In my view a serious one) Works fine with Maven 3.0 through 3.2.5 Fails with 3.3.1 and 3.3.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5863) default pom's release-profile should use goal jar-no-fork instead of jar
Petr Kozelka created MNG-5863: - Summary: default pom's release-profile should use goal jar-no-fork instead of jar Key: MNG-5863 URL: https://issues.apache.org/jira/browse/MNG-5863 Project: Maven Issue Type: Bug Components: POM Affects Versions: 3.3.3 Reporter: Petr Kozelka in maven-model-builder, the file pom-4.0.0.xml defines release-profile which binds some executions to the lifecycle. One of them is source:jar - which forks the build. That can be a problem in some configurations, and the forking is probably not necessary. One situation where the forked build hurts is this: - I have checkstyle:check attached to phase validate - some of my modules generate code, obviously not compliant to the checkstyle The problem is that, inside forked build, the checkstyle:check is called again, but now it checks also the generated code (because target/ is no longer empty). And of course fails. Even worse: during normal development iterations, everything is fine. But when I have to issue a release (usually under some pressure), I hit this problem. Fortunately, there _is_ a workaround: override the execution attach-sources and assign it to a non-existing phase, and define execution with different id for that. But it is too ugly and I believe that the simple fix would solve it - for the meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5840) relativePath is used if the groupId and artifactId match irrespective of the version
[ https://issues.apache.org/jira/browse/MNG-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14638930#comment-14638930 ] ASF GitHub Bot commented on MNG-5840: - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/60#issuecomment-124129817 I'm out in the middle of nowhere, but i'll cancel the vote, test and re-roll once I'm back to civilization. relativePath is used if the groupId and artifactId match irrespective of the version -- Key: MNG-5840 URL: https://issues.apache.org/jira/browse/MNG-5840 Project: Maven Issue Type: Bug Affects Versions: 3.3.1, 3.3.3 Reporter: Stephen Connolly Assignee: Stephen Connolly Labels: regression Fix For: 3.3.5 Attachments: mng-5840-testcase.tar.gz This is a regression. (In my view a serious one) Works fine with Maven 3.0 through 3.2.5 Fails with 3.3.1 and 3.3.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5840) relativePath is used if the groupId and artifactId match irrespective of the version
[ https://issues.apache.org/jira/browse/MNG-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14638956#comment-14638956 ] Hudson commented on MNG-5840: - SUCCESS: Integrated in maven-3.x #1096 (See [https://builds.apache.org/job/maven-3.x/1096/]) [MNG-5840] The fix for parent version validation caused a regression in the parent version range (stephen.alan.connolly: rev bd87258629db8e3fcc7aa04777afc16314c3cde0) * maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java * maven-model-builder/pom.xml relativePath is used if the groupId and artifactId match irrespective of the version -- Key: MNG-5840 URL: https://issues.apache.org/jira/browse/MNG-5840 Project: Maven Issue Type: Bug Affects Versions: 3.3.1, 3.3.3 Reporter: Stephen Connolly Assignee: Stephen Connolly Labels: regression Fix For: 3.3.5 Attachments: mng-5840-testcase.tar.gz This is a regression. (In my view a serious one) Works fine with Maven 3.0 through 3.2.5 Fails with 3.3.1 and 3.3.3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5863) default pom's release-profile should invoke source plugin with goal jar-no-fork instead of jar
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka updated MNG-5863: -- Summary: default pom's release-profile should invoke source plugin with goal jar-no-fork instead of jar (was: default pom's release-profile should invoke source with goal jar-no-fork instead of jar) default pom's release-profile should invoke source plugin with goal jar-no-fork instead of jar -- Key: MNG-5863 URL: https://issues.apache.org/jira/browse/MNG-5863 Project: Maven Issue Type: Bug Components: POM Affects Versions: 3.3.3 Reporter: Petr Kozelka Original Estimate: 0.25h Remaining Estimate: 0.25h in maven-model-builder, the file pom-4.0.0.xml defines release-profile which binds some executions to the lifecycle. One of them is source:jar - which forks the build. That can be a problem in some configurations, and the forking is probably not necessary. One situation where the forked build hurts is this: - I have checkstyle:check attached to phase validate - some of my modules generate code, obviously not compliant to the checkstyle The problem is that, inside forked build, the checkstyle:check is called again, but now it checks also the generated code (because target/ is no longer empty). And of course fails. Even worse: during normal development iterations, everything is fine. But when I have to issue a release (usually under some pressure), I hit this problem. Fortunately, there _is_ a workaround: override the execution attach-sources and assign it to a non-existing phase, and define execution with different id for that. But it is too ugly and I believe that the simple fix would solve it - for the meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5863) default pom's release-profile should invoke source with goal jar-no-fork instead of jar
[ https://issues.apache.org/jira/browse/MNG-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Petr Kozelka updated MNG-5863: -- Summary: default pom's release-profile should invoke source with goal jar-no-fork instead of jar (was: default pom's release-profile should use goal jar-no-fork instead of jar) default pom's release-profile should invoke source with goal jar-no-fork instead of jar --- Key: MNG-5863 URL: https://issues.apache.org/jira/browse/MNG-5863 Project: Maven Issue Type: Bug Components: POM Affects Versions: 3.3.3 Reporter: Petr Kozelka Original Estimate: 0.25h Remaining Estimate: 0.25h in maven-model-builder, the file pom-4.0.0.xml defines release-profile which binds some executions to the lifecycle. One of them is source:jar - which forks the build. That can be a problem in some configurations, and the forking is probably not necessary. One situation where the forked build hurts is this: - I have checkstyle:check attached to phase validate - some of my modules generate code, obviously not compliant to the checkstyle The problem is that, inside forked build, the checkstyle:check is called again, but now it checks also the generated code (because target/ is no longer empty). And of course fails. Even worse: during normal development iterations, everything is fine. But when I have to issue a release (usually under some pressure), I hit this problem. Fortunately, there _is_ a workaround: override the execution attach-sources and assign it to a non-existing phase, and define execution with different id for that. But it is too ugly and I believe that the simple fix would solve it - for the meantime before the whole profile is removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5864) optional attribute validation
Vsevolod Golovanov created MNG-5864:
---
Summary: optional attribute validation
Key: MNG-5864
URL: https://issues.apache.org/jira/browse/MNG-5864
Project: Maven
Issue Type: Bug
Affects Versions: 3.3.3
Environment: JBoss Developer Studio 8.1.0.GA
Reporter: Vsevolod Golovanov
I have some dependencies, whose {{optional}} attributes are defined by property
expressions. E.g.:
{code}
dependency
!-- ... --
optional${someProperty}/optional
/dependency
{code}
This works fine, but leads to validation errors in JBoss Developer Studio:
{noformat}
cvc-datatype-valid.1.2.1: '${someProperty}' is not a valid value for 'boolean'.
cvc-type.3.1.3: The value '${someProperty}' of element 'optional' is not valid.
{noformat}
I far as I understand the problem is in [the
XSD|http://maven.apache.org/xsd/maven-4.0.0.xsd]:
{code}
xs:element name=optional minOccurs=0 type=xs:boolean default=false
{code}
It's defined as boolean, yet [Maven
Model|http://maven.apache.org/ref/3.3.3//maven-model/maven.html] says:
{quote}Note: While the type of this field is String for technical reasons, the
semantic type is actually Boolean.{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MASSEMBLY-780) Snappy supported
[ https://issues.apache.org/jira/browse/MASSEMBLY-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned MASSEMBLY-780: -- Assignee: Benson Margulies Snappy supported Key: MASSEMBLY-780 URL: https://issues.apache.org/jira/browse/MASSEMBLY-780 Project: Maven Assembly Plugin Issue Type: New Feature Reporter: Benson Margulies Assignee: Benson Margulies Plexus archiver supports snappy. So maven-assembly can, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MASSEMBLY-780) Snappy supported
[ https://issues.apache.org/jira/browse/MASSEMBLY-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies resolved MASSEMBLY-780. Resolution: Fixed Fix Version/s: 3.0.0 1692379: added .tar.snappy. Snappy supported Key: MASSEMBLY-780 URL: https://issues.apache.org/jira/browse/MASSEMBLY-780 Project: Maven Assembly Plugin Issue Type: New Feature Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 3.0.0 Plexus archiver supports snappy. So maven-assembly can, too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
