[jira] (MEAR-145) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEAR-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-145. Resolution: Fixed Applied, thanks! > Add Maven version used to Created-By entry in manifest > -- > > Key: MEAR-145 > URL: https://jira.codehaus.org/browse/MEAR-145 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: n/a >Reporter: Anders Hammar >Assignee: Stephane Nicoll > Fix For: 2.8 > > Attachments: MEAR-145.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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] (MEAR-145) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEAR-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-145: - Fix Version/s: 2.8 Assignee: Stephane Nicoll > Add Maven version used to Created-By entry in manifest > -- > > Key: MEAR-145 > URL: https://jira.codehaus.org/browse/MEAR-145 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: n/a >Reporter: Anders Hammar >Assignee: Stephane Nicoll > Fix For: 2.8 > > Attachments: MEAR-145.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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] (MEAR-145) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEAR-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MEAR-145 started by Stephane Nicoll. > Add Maven version used to Created-By entry in manifest > -- > > Key: MEAR-145 > URL: https://jira.codehaus.org/browse/MEAR-145 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: n/a >Reporter: Anders Hammar >Assignee: Stephane Nicoll > Fix For: 2.8 > > Attachments: MEAR-145.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289592#comment-289592 ] Stephane Nicoll commented on MEAR-146: -- I am confused. library-directory is only written if you set the defaultLibDirectory. If I understand you well, you're saying you must use it (to use the magic APP-INF/lib thing) but we should not write the value in that case? I believe you're asking here to workaround a bug in Weblogic, right. Has this been reported by any chance? > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.8 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- 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] (MEAR-141) No way to configure generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MEAR-141.
Resolution: Fixed
> No way to configure generate env-entry elements in generated application.xml
>
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stephane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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] (MEAR-141) No way to configure generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MEAR-141:
-
Summary: No way to configure generate env-entry elements in generated
application.xml (was: No way to programmatically generate env-entry elements
in generated application.xml)
> No way to configure generate env-entry elements in generated application.xml
>
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stephane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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] (MEAR-141) No way to programmatically generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MEAR-141 started by Stephane Nicoll.
> No way to programmatically generate env-entry elements in generated
> application.xml
> ---
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stephane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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] (MEAR-141) No way to programmatically generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MEAR-141:
-
Fix Version/s: 2.8
Assignee: Stephane Nicoll
> No way to programmatically generate env-entry elements in generated
> application.xml
> ---
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stephane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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] (MEAR-141) No way to programmatically generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289591#comment-289591
]
Stephane Nicoll commented on MEAR-141:
--
Jim Brownfield provided a patch for this one which I am currently reviewing and
adapting.
> No way to programmatically generate env-entry elements in generated
> application.xml
> ---
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stephane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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] (MEAR-144) Allow multiple versions of web module inside a single EAR
[ https://jira.codehaus.org/browse/MEAR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-144. Resolution: Won't Fix That's not going to work. The Maven dependency identity mechanism is such that you can't have multiple versions of the same artifact. > Allow multiple versions of web module inside a single EAR > - > > Key: MEAR-144 > URL: https://jira.codehaus.org/browse/MEAR-144 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.1, 2.2 > Environment: GNU/Linux x86_64 Ubuntu >Reporter: wing-tung Leung >Priority: Minor > > Current Maven EAR plugin seems not to support explicit version for web > modules. > This would be useful for generating EAR which contains multiple versions of a > web module (under different context roots), enabling online users to switch > back and forth between old and new releases from the web application. > http://maven.apache.org/plugins/maven-ear-plugin/modules.html#awebModule -- 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-627) Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories
[ https://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289584#comment-289584 ] Dan Carleton commented on MRELEASE-627: --- Ran into this today. Without this patch I'll resort to some clunky shell scripts I'm afraid. > Fix multi-repository support in the release plugin and make it work with e.g. > mercurial subrepositories > --- > > Key: MRELEASE-627 > URL: https://jira.codehaus.org/browse/MRELEASE-627 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Henning Schmiedehausen > Attachments: MRELEASE-627-2, release-plugin-patch > > > The maven-release-plugin is pretty much designed to work with a single > repository and tag and branch from this. As soon as a project tree is more > complex and e.g. uses nested or multiple repositories (such as the Mercurial > subrepos), it fails. > The attached patch fixes most of the use cases that allow releasing large > (reactor) projects that span multiple projects and use one repository per > project. > New properties: > revertOrder (boolean) - Default: false > Reverts the order in which commit, tag and branch process multi-repos. E.g. > in Mercurial, the main repository (which contains the subrepos) must be > processed last, because it implicitly records state of the relationship > between the main and the sub repository. If it gets committed first, then > this state is not recorded correctly. By reverting the order, the main > repository is committed last. > commitAllChanges (boolean) - Default: false > The release plugin tries to explicitly list which files it commits. However, > in the case of a multi-repository tree, in then tries e.g. to commit > repo/pom.xml, repo/a/pom.xml and repo/b/pom.xml in the context of "repo" > which then fails (because repo/a/pom.xml and repo/b/pom.xml are actually part > of the subrepos a and b). Setting this parameters omits the list of files and > tells the SCM to "commit everything". E.g. Mercurial then picks up the > changes correctly and also records the implicit state between master and sub > repositories correctly. > tagByProject, branchByProject (boolean) - Default: false > Similar to the existing 'commitByProject', these options select whether a tag > or a branch should be created by running the tag command in the root of the > tree or by looping through all projects and tagging or branching them > one-by-one. Default is to tag in the root. > tagRequiresCommit / branchRequiresCommit (boolean) - Default: false > Mercurial manages tags by adding entries to the '.hgtags' file, which is > managed implicitly by the SCM. If a subrepository gets tagged as part of a > larger, multi-repo project, then the changes must be explicitly committed, > else they don't get picked up by the main repository. This sounds more > complicated than it actually is, the summary is that "this must be 'true' for > Mercurial and probably "false" for everything else. > Those changes *should* work with the 1.4 SCM provider, but were tested only > with the 1.5-SNAPSHOT release. It also benefits from fixing the pushChanges > support in the Mercurial provider. > If you want to test drive this patch, you should also be interested in > SCM-587. -- 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] (MEJB-56) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEJB-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289580#comment-289580 ] Dennis Lundberg commented on MEJB-56: - Hi Anders, I tried applying your patch, but it doesn't apply for me. I'll try manually instead. Just so that I've got it right: You renamed the src/it/manifest-classpath to src/it/manifest-content and modified the verify script by adding a check on the Created-By attribute? > Add Maven version used to Created-By entry in manifest > -- > > Key: MEJB-56 > URL: https://jira.codehaus.org/browse/MEJB-56 > Project: Maven 2.x EJB Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: n/a >Reporter: Anders Hammar > Attachments: MEJB-56.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289576#comment-289576
]
Kristian Rosenvold commented on SUREFIRE-809:
-
Oops. Sorry about running the release here. Let me know if it needs to be
cancelled ;) Or maybe this should be in the release notes ;)
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-810) Endorsed dirs mechanism not working
[
https://jira.codehaus.org/browse/SUREFIRE-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-810:
Fix Version/s: 2.12
> Endorsed dirs mechanism not working
> ---
>
> Key: SUREFIRE-810
> URL: https://jira.codehaus.org/browse/SUREFIRE-810
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.11
>Reporter: José Cervera
>Assignee: Kristian Rosenvold
> Fix For: 2.12
>
> Attachments: pom.xml, TestSurefire.java, TEST-TestSurefire.xml
>
>
> The endorsed mechanism doesn't seem to work.
> You can reproduce this test by creating a new maven project, placing the java
> file in test/java, and using the provided pom.xml
> The test class checks the jar from which the WebFault class is loaded. It's
> expected to use the one in the webservices library, as can be checked by
> executing the test from command line with the required parameters.
> When executing mvn test, the test fails:
> C:\Users\Jose\\SurefireBug>mvn test
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - SurefireBug:SurefireBug:jar:0.0.1-SNAPSHOT
> [INFO]task-segment: [test]
> [INFO]
>
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources,i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [dependency:copy {execution: process}]
> [INFO] Configured Artifact: org.glassfish.metro:webservices-rt:2.2-b10:jar
> [INFO] Configured Artifact: org.glassfish.metro:webservices-api:2.2-b10:jar
> [INFO] org.glassfish.metro:webservices-rt:2.2-b10:jar already exists in
> C:\Users\Jose\\SurefireBug\target\endorsed
> [INFO] org.glassfish.metro:webservices-api:2.2-b10:jar already exists in
> C:\Users\Jose\\SurefireBug\target\endorsed
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources {execution: default-testResources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources,
> i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO] [dependency:copy-dependencies {execution: install}]
> [INFO] junit-4.10.jar already exists in destination.
> [INFO] javax.annotation-3.1.1-b06.jar already exists in destination.
> [INFO] webservices-api-2.2-b10.jar already exists in destination.
> [INFO] webservices-rt-2.2-b10.jar already exists in destination.
> [INFO] hamcrest-core-1.1.jar already exists in destination.
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [surefire:test {execution: default-test}]
> [INFO] Surefire report directory:
> C:\Users\Jose\\SurefireBug\target\surefire-reports
> ---
> T E S T S
> ---
> Running TestSurefire
> WebFault class:/C:/Program%20Files/Java/jdk1.6.0_25/jre/lib/rt.jar
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec <<<
> FAILURE!
> Results :
> Failed tests: test(TestSurefire)
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] There are test failures.
> Please refer to C:\Users\Jose\\SurefireBug\target\surefire-reports for
> the individual test results.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Wed Dec 14 13:18:49 CET 2011
> [INFO] Final Memory: 25M/346M
> [INFO]
>
> And from command line:
> C:\Users\Jose\\SurefireBug>java -Djava.endorsed.dirs=target\endorsed
> -classpath
> target\test-classes;target\lib\hamcrest-core-1.1.jar;target\lib\junit-4.10.jar;target\lib\webservices-api-2.2-b10.jar;target\lib\webservices-rt-2.2-b10.jar
> org.junit.runner.JUnitCore TestSurefire
> JUnit version 4.10
> .WebFault
> class:/C:/Users/Jose/agentmanagement/SurefireBug/target/endorsed/webservices-api-2.2-b10.jar
> Time: 0,005
> OK (1 test)
> I've tried changing the forkMode, useSystemClassLoader and childDelegation
> parameters.
> In the Test report we can see that the java.endorsed.dirs property
[jira] (MRELEASE-731) Change Maven prerequisite from 2.0.9 to 2.2.1
Robert Scholte created MRELEASE-731:
---
Summary: Change Maven prerequisite from 2.0.9 to 2.2.1
Key: MRELEASE-731
URL: https://jira.codehaus.org/browse/MRELEASE-731
Project: Maven 2.x Release Plugin
Issue Type: Task
Affects Versions: 2.2.2
Reporter: Robert Scholte
Upgrading the plexus-utils might solve a couple of issues, but is now locked at
1.5.8.
When upgrading this to a more recent version a lot of tests fail due to a CNFE:
{noformat}
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Unable to lookup component 'org.apache.maven.project.MavenProjectBuilder', it
could not be started
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:339)
at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:216)
at
org.apache.maven.shared.release.phase.AbstractReleaseTestCase.setUp(AbstractReleaseTestCase.java:99)
at
org.apache.maven.shared.release.phase.ScmCommitPreparationPhaseTest.setUp(ScmCommitPreparationPhaseTest.java:72)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLifecycleException:
Error starting component
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:109)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331)
... 16 more
Caused by:
org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionException:
Error composing component
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105)
... 19 more
Caused by: org.codehaus.plexus.component.composition.CompositionException:
Composition failed of field profilesBuilder in object of type
org.apache.maven.project.DefaultMavenProjectBuilder because the requirement
ComponentRequirement{role='org.apache.maven.profiles.MavenProfilesBuilder',
roleHint='null', fieldName='null'} was missing
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:154)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29)
... 21 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Unable to lookup component 'org.apache.maven.profiles.MavenProfilesBuilder', it
could not be created
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:335)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129)
... 25 more
Caused by:
org.codehaus.plexus.component.factory.ComponentInstantiationException: Could
not instanciate component: role:
'org.apache.maven.profiles.MavenProfilesBuilder', implementation:
'org.apache.maven.prof
[jira] (SUREFIRE-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-799: Issue Type: New Feature (was: Improvement) > Allow test parallelisation when forkMode=always > --- > > Key: SUREFIRE-799 > URL: https://jira.codehaus.org/browse/SUREFIRE-799 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.10 > Environment: all >Reporter: nkeywal >Assignee: Kristian Rosenvold > Fix For: 2.12 > > Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch > > > Surefire already allows: > - forking > - parallelization within a JVM > Mixing both features would mean forking multiple JVM instead of only one. > It would allow to parallelize tests that need to be executed in a separate > JVM (i.e.: with forkMode=always). Usually these tests take longer than the > simple ones. In our case, 40% of the tests are executed in 4 minutes, the > other 60% need two hours. So it's obviously more interesting to parallelize > the former, but these ones need to fork. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-799: Fix Version/s: 2.12 > Allow test parallelisation when forkMode=always > --- > > Key: SUREFIRE-799 > URL: https://jira.codehaus.org/browse/SUREFIRE-799 > Project: Maven Surefire > Issue Type: Improvement > Components: process forking >Affects Versions: 2.10 > Environment: all >Reporter: nkeywal >Assignee: Kristian Rosenvold > Fix For: 2.12 > > Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch > > > Surefire already allows: > - forking > - parallelization within a JVM > Mixing both features would mean forking multiple JVM instead of only one. > It would allow to parallelize tests that need to be executed in a separate > JVM (i.e.: with forkMode=always). Usually these tests take longer than the > simple ones. In our case, 40% of the tests are executed in 4 minutes, the > other 60% need two hours. So it's obviously more interesting to parallelize > the former, but these ones need to fork. -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
Alex Halovanic created MEAR-146: --- Summary: Expose parameter to not write library-directory element in application.xml Key: MEAR-146 URL: https://jira.codehaus.org/browse/MEAR-146 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.8 Environment: Oracle WebLogic Reporter: Alex Halovanic Priority: Minor Attachments: ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch The current handling of defaultLibBundleDir leads to some issues on Oracle Weblogic 10+. The Ear plugin currently sets library-directory to the value of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's classloading features break (specifically "Generic File Loading") when this element is set. defaultLibBundleDir has to be set to APP-INF/lib since this is the magic library folder for WebLogic. The patch adds a parameter to prevent setting library-directory for cases like this. -- 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] (MSHARED-206) do some interpolation from pom values during manifest generation
[ https://jira.codehaus.org/browse/MSHARED-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-206: --- Fix Version/s: (was: maven-archiver-2.5) > do some interpolation from pom values during manifest generation > > > Key: MSHARED-206 > URL: https://jira.codehaus.org/browse/MSHARED-206 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-archiver >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] (SUREFIRE-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289569#comment-289569
]
Kristian Rosenvold commented on SUREFIRE-809:
-
I think the filter approach sounds excellent, at least for the JUnit part. I
don't really know about the testng details
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
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-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
[
https://jira.codehaus.org/browse/MASSEMBLY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-595.
Resolution: Fixed
Fixed in r1235501
> Tar file contains world-writeable files when fileSets with and without
> fileMode are mixed
> -
>
> Key: MASSEMBLY-595
> URL: https://jira.codehaus.org/browse/MASSEMBLY-595
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Joseph Walton
>Assignee: Kristian Rosenvold
> Fix For: 2.3
>
> Attachments:
> 0001-MASSEMBLY-595-Upgrade-to-pick-up-PLXCOMP-196-and-PLX.patch,
> MASSEMBLY-595.tar.gz
>
>
> I have an assembly descriptor with some fileSets that do and some that don't
> set the fileMode. Any resources after fileMode has been set end up with
> world-writable permissions.
> This assembly descriptor:
> {code}
>
> dist
>
> tar.gz
>
>
>
> src/main/files
> a
>
>
> src/main/files
> b
> 0744
>
>
> src/main/files
> c
>
>
>
> {code}
> gives:
> {code}
> $ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
> drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
> -rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
> drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
> -rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
> drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
> -rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
> {code}
> The third copy of the fileSet, with no {{fileMode}} set, is now
> world-writable, unlike the first. The second directory, with no
> {{directoryMode}} specified, has the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-660) Perforce Provider does not pass client specification to p4 for blame command
Matthew Madson created SCM-660: -- Summary: Perforce Provider does not pass client specification to p4 for blame command Key: SCM-660 URL: https://jira.codehaus.org/browse/SCM-660 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.6 Reporter: Matthew Madson Attachments: Updated_Blame_command_to_utilize_clientspec.patch The blame command does not use the clientspec generated by the application, the patch file should fix the problem. -- 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] (MWAR-246) NullPointerException Processing Web Resources
[ https://jira.codehaus.org/browse/MWAR-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MWAR-246: - Fix Version/s: (was: 2.2) 2.3 > NullPointerException Processing Web Resources > - > > Key: MWAR-246 > URL: https://jira.codehaus.org/browse/MWAR-246 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Linux, JDK 6 >Reporter: Gary Murphy > Fix For: 2.3 > > > NullPointerException on packaging of web resources. Configuration is: > > maven-war-plugin > > > > >xercesImpl-*.jar > > > > > > Stack trace is: > Execution default-war of goal > org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) > 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 > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war > failed. > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) > ... 19 more > Caused by: java.lang.NullPointerException > at java.io.File.(File.java:222) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:124) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:91) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:197) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:159) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) > ... 20 more -- 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] (MWAR-218) Missed XSD Schema for the file webapp-cache.xml
[
https://jira.codehaus.org/browse/MWAR-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-218:
-
Fix Version/s: (was: 2.2)
2.3
> Missed XSD Schema for the file webapp-cache.xml
> ---
>
> Key: MWAR-218
> URL: https://jira.codehaus.org/browse/MWAR-218
> Project: Maven 2.x WAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.1-beta-1
>Reporter: Felipe Gaúcho
> Fix For: 2.3
>
>
> When packaging a web-application, maven-war-plugin generates a cache file, as
> described here:
> http://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html#cacheFile
> This cache file is an XML file but the generated file doesn't contains an
> Schema or DTD declaration on its header. This makes impossible to validate
> such file, generating warnings in the most common Java IDEs. Since it is a
> mandatory XML file I believe it should has a model specification somewhere (a
> XSD Schema I hope), eventually just not released for public usage.
> The steps I expect to make Maven 2 WAR plugin better:
> - to modify the generator of the webapp-cache.xml file to include the proper
> XML header (with namespace and schema location)
> - to make the schema of such file publicly available, in order to give the
> developers and automatic tools a chance to validate any error in a deployable
> artifact.
> This will give us a chance to detect potential bugs before to deploy a
> web-application.
> --- The expected header is something like:
> {code:xml}
>
> http://maven.apache.org/plugins/maven-war-plugin";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-war-plugin
> http://maven.apache.org/???/???.xsd";>
> ...
>
> {code}
--
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-588) Build fails because of 'ls -1nlaR /'
[ https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-588. Resolution: Fixed Fixed in r1235501 > Build fails because of 'ls -1nlaR /' > > > Key: MASSEMBLY-588 > URL: https://jira.codehaus.org/browse/MASSEMBLY-588 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: Ubuntu 11.10 (oneiric) >Reporter: Thomas Pasch >Assignee: Kristian Rosenvold > Fix For: 2.3 > > Attachments: partial_log.bz2 > > > This is a report again > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) used in conjunction with maven 3.0.3. I'm trying to build > ebml-viewer from svn r126 (lastest) at > http://code.google.com/p/ebml-viewer/source/checkout . Build fails on Linux, > but the developer of ebml-viewer reports that it builds fine on Windows. > Last lines of output from failed build with 'mvn -DskipTests -X -e package > 2>&1 | tee log': > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2:37.924s > [INFO] Finished at: Tue Dec 06 20:30:47 CET 2011 > [INFO] Final Memory: 8M/216M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > 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:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error creating assembly archive bin: Failed to retrieve numeric > file attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:504) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error creating assembly archive bin: Failed to retrieve numeric file > attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:189) > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:445) > ... 21 more > Caused by: org.codehaus.plexus.archiver.ArchiverException: Failed to retrieve > numer
[jira] (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ https://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MWAR-33: Fix Version/s: (was: 2.2) 2.3 > jars with differents versions can be in WEB-INF/lib with war as dependencies > > > Key: MWAR-33 > URL: https://jira.codehaus.org/browse/MWAR-33 > Project: Maven 2.x WAR Plugin > Issue Type: Bug > Environment: all >Reporter: Olivier Lamy >Assignee: Stephane Nicoll > Fix For: 2.3 > > Attachments: MWAR-33-example.zip, MWAR-33-workaround.zip > > Original Estimate: 15 minutes > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > My pom has the following dependencies : > - log4j:log4j:1.2.13 > - a war with log4j:log4j:1.2.11 included > Result the two jars are in WEB-INF/lib. -- 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] (MWAR-241) Overlay and an empty classifier
[
https://jira.codehaus.org/browse/MWAR-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-241:
-
Fix Version/s: (was: 2.2)
2.3
> Overlay and an empty classifier
> ---
>
> Key: MWAR-241
> URL: https://jira.codehaus.org/browse/MWAR-241
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.1-beta-1
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_18
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Sergiy Shyrkov
> Fix For: 2.3
>
>
> I have an issue with the WAR overlay and an empty classifier.
> My use case:
> I am including an overlay with a "dynamic" classifier value. Meaning that I
> set the classifier either to an empty value "" (equivalent to no classifier
> for an artifact) or to a "test" value if the corresponding profile is
> activated.
>
> ...
>
> org.jahia.server
> jahia-war
> 1.0
> ${jahia.war.classifier}
> war
> runtime
>
>
>
>
>
> org.apache.maven.plugins
> maven-war-plugin
>
> ${jahia.war.classifier}
>
>
> org.jahia.server
> jahia-war
> ${jahia.war.classifier}
>
>
> gwt/**
>
>
>
> ...
> When I launch "normal" build (mvn clean package), the value of my classifier
> property (${jahia.war.classifier}) is empty and I am getting the following
> error:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] overlay[ id org.jahia.server:jahia-war] is not a dependency of the
> project.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: overlay[ id
> org.jahia.server:jahia-war] is not a dependency of t
> he project.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:55
> 6)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
> a:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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 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)
> Caused by:
> org.apache.maven.plugin.war.overlay.InvalidOverlayConfigurationException:
> overlay[ id org.jahia.server:jahia-
> war] is not a dependency of the project.
> at
> org.apache.maven.plugin.war.overlay.OverlayManager.getAssociatedArtifact(OverlayManager.java:223)
> at
> org.apache.maven.plugin.war.overlay.OverlayManager.initialize(OverlayManager.java:146)
> at
> org.apache.maven.plugin.war.overlay.OverlayManager.(OverlayManager.java:76)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:433)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:394)
> at
> org.apa
[jira] (MWAR-167) Final manifest not written to exploded location
[ https://jira.codehaus.org/browse/MWAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MWAR-167: - Fix Version/s: (was: 2.2) 2.3 > Final manifest not written to exploded location > --- > > Key: MWAR-167 > URL: https://jira.codehaus.org/browse/MWAR-167 > Project: Maven 2.x WAR Plugin > Issue Type: Bug > Components: manifest >Affects Versions: 2.1-alpha-1 >Reporter: Paul Benedict > Fix For: 2.3 > > Attachments: mvn167-with-it.diff, patch.diff > > > When I open up my generated WAR file, the Manifest file contains all the > entries I specified. This is correct. However, when I look into the exploded > location, it's just the file I had in my project to begin with. > The exploded Manifest should be updated with the final contents. -- 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] (MWAR-164) Support for specifying which encoding to use when filtering resources
[
https://jira.codehaus.org/browse/MWAR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-164:
-
Fix Version/s: (was: 2.2)
2.3
> Support for specifying which encoding to use when filtering resources
> -
>
> Key: MWAR-164
> URL: https://jira.codehaus.org/browse/MWAR-164
> Project: Maven 2.x WAR Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.1-alpha-1
>Reporter: kai lilleby
> Fix For: 2.3
>
> Attachments: MWAR-164-maven-war-plugin.patch
>
>
> Quoting Hervé:
> {quote}
> Maven filtering provides an encoding parameter to set encoding used when
> reading/writing files. But war plugin uses null value, which means platform
> encoding... Sorry, encoding support won't be totally "free" ;)
> I added TODOs in the code.
> For web.xml and container config XML file, I set encoding to UTF-8, which is a
> better default value than platform encoding.
> For other filtered resources, you'll need to add an encoding attribute to
> o.a.m.model.Resource class, to let the user define which encoding he wants to
> use when filtering. Perhaps using project.build.sourceEncoding as a default
> value is a good idea.
> Seems like this is worth a Jira issue to track this new feature.
> {quote}
--
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] (MWAR-187) regression running war packaging with maven 2.1
[
https://jira.codehaus.org/browse/MWAR-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-187:
-
Fix Version/s: (was: 2.2)
2.3
> regression running war packaging with maven 2.1
> ---
>
> Key: MWAR-187
> URL: https://jira.codehaus.org/browse/MWAR-187
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-beta-1
> Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
> Java version: 1.6.0_11
> Java home: D:\platina\java\jdk6\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: nicolas de loof
>Priority: Minor
> Fix For: 2.3
>
> Attachments: MWAR-187-bad_webapp_cache.zip
>
>
> Using plugin version 2.1-beta-1, my webapp can't get packaged.
> It can be fixed by downgrading the plugin to 2.0.2
> {code}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-war-plugin:2.1-beta-1:w
> ar' -->
> [DEBUG] (s) archiveClasses = false
> [DEBUG] (s) attachClasses = false
> [DEBUG] (s) cacheFile = D:\...\target\war\work\webapp-cache.xml
> [DEBUG] (s) classesClassifier = classes
> [DEBUG] (s) classesDirectory = D:\...\target\classes
> [DEBUG] (f) escapedBackslashesInFilePath = false
> [DEBUG] (s) failOnMissingWebXml = true
> [DEBUG] (f) filteringDeploymentDescriptors = false
> [DEBUG] (s) outputDirectory = D:\...\target
> [DEBUG] (s) primaryArtifact = true
> [DEBUG] (s) project = MavenProject:
> com.sfr.bios.pdc:bios-pdc-webservices:1.0.
> 0-SNAPSHOT @ D:\...\pom.xml
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@10f0a0
> [DEBUG] (s) useCache = true
> [DEBUG] (s) warName = bios-pdc
> [DEBUG] (s) warSourceDirectory = D:\...\src\main\webapp
> [DEBUG] (s) webappDirectory =
> D:\...\target\bios-pdc-webservices-1.0.0-SNAPSHOT
> [DEBUG] (s) workDirectory = D:\...\target\war\work
> [DEBUG] -- end configuration --
> [INFO] [war:war]
> [INFO] Packaging webapp
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] modelEncoding : modelEncoding : modelEncoding : modelEncoding
> Debugging information
> message : modelEncoding : modelEncoding
> cause-exception :
> com.thoughtworks.xstream.mapper.CannotResolveClassExceptio
> n
> cause-message : modelEncoding : modelEncoding
> class : org.apache.maven.plugin.war.util.WebappStructure
> required-type : org.apache.maven.model.Dependency
> path:
> /webapp-structure/dependenciesInfo/org.apache.maven.plugin
> .war.util.DependencyInfo/dependency/modelEncoding
> line number : 156
> ---
> [INFO]
>
> [INFO] Trace
> com.thoughtworks.xstream.converters.ConversionException: modelEncoding :
> modelEn
> coding : modelEncoding : modelEncoding
> Debugging information
> message : modelEncoding : modelEncoding
> cause-exception :
> com.thoughtworks.xstream.mapper.CannotResolveClassExceptio
> n
> cause-message : modelEncoding : modelEncoding
> class : org.apache.maven.plugin.war.util.WebappStructure
> required-type : org.apache.maven.model.Dependency
> path:
> /webapp-structure/dependenciesInfo/org.apache.maven.plugin
> .war.util.DependencyInfo/dependency/modelEncoding
> line number : 156
> ---
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
> er.java:89)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
> bstractReferenceUnmarshaller.java:63)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
> arshaller.java:76)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.unmarshallField(AbstractReflectionConverter.java:246)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.doUnmarshal(AbstractReflectionConverter.java:218)
> at
> com.thoughtworks.xstream.converters.reflection.AbstractReflectionConv
> erter.unmarshal(AbstractReflectionConverter.java:162)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshall
> er.java:82)
> at
> com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(A
> bstractReferenceUnmarshaller.java:63)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnm
> arshaller.java:76)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.conv
[jira] (MWAR-168) "Dependency Has Changed" Incorrectly Reported
[
https://jira.codehaus.org/browse/MWAR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MWAR-168:
-
Fix Version/s: (was: 2.2)
2.3
> "Dependency Has Changed" Incorrectly Reported
> -
>
> Key: MWAR-168
> URL: https://jira.codehaus.org/browse/MWAR-168
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-2
>Reporter: gotama
>Assignee: Stephane Nicoll
> Fix For: 2.3
>
>
> In maven-war-plugin 2.1-alpha-2, execute the following on a war project:
> mvn clean;
> mvn install;
> mvn install;
> The 3rd command incorrectly lists messages for each dependency as follows:
> [INFO] Dependency[Dependency {groupId=com.mycompany, artifactId=myartifact,
> version=8.6.1, type=jar}]
> has changed (was Dependency {groupId=com.mycompany, artifactId=myartifact,
> version=8.6.1, type=jar}).
> The first time that mvn install is run, dependencies are added to:
> target\myapp-war-1.1-SNAPSHOT\WEB-INF\lib
> The second invocation of mvn install appears to fail in comparing the
> existing jars in the above path with what is in the repository. The message
> states the dependencies have changed when in fact they have not.
> This problem does not exist in maven-war-plugin 2.0.2.
--
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] (MWAR-255) " Negative time"
[ https://jira.codehaus.org/browse/MWAR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MWAR-255: Fix Version/s: (was: 2.1.2) > " Negative time" > > > Key: MWAR-255 > URL: https://jira.codehaus.org/browse/MWAR-255 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Linux x64, JDK 1.6.0_25, Maven 3.0.3 >Reporter: Roman Ksoenko > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project > library: Execution default-war of goal > org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Negative time -> > [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on > project library: Execution default-war of goal > org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Negative time > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) > 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:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > 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 > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war > failed: Negative time > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: java.lang.IllegalArgumentException: Negative time > at java.io.File.setLastModified(File.java:1258) > at > org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:295) > at > org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask$1.registered(AbstractWarPackagingTask.java:150) > at > org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:211) > at > org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:145) > at > org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFiles(AbstractWarPackagingTask.java:103) > at > org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFiles(AbstractWarPackagingTask.java:125) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handeWebAppSourceDirectory(WarProjectPackagingTask.java:168) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:93) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:197) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:159) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... 20 more > [ERROR] > [ERROR] > This occurs when I have in src/main/webapp/ files with date 1970-01-01 and > it's a rather hard to discover thi
[jira] (MJAR-69) When 'index' and 'addClasspath' are both true, plugin fails.
[
https://jira.codehaus.org/browse/MJAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MJAR-69.
--
Resolution: Fixed
Fixed in r1235030
> When 'index' and 'addClasspath' are both true, plugin fails.
>
>
> Key: MJAR-69
> URL: https://jira.codehaus.org/browse/MJAR-69
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Anagnostopoulos Kostis
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: trace.log
>
>
> When both the 'index' and 'addClasspath' are true, the plugin fails to create
> jar with the following msg:
> Embedded error: Problem creating jar: **/target/classes (Is a directory)
> A typical configuration to produce the error would be:
> {code:xml}
>
> maven-jar-plugin
>
>
> true
>
> true
>
>
>
> {code}
> The issue below (about including dependency files in index) claims that it
> introduced this bug:
> http://jira.codehaus.org/browse/MJAR-40
> I'm posting this issue so that to ensure that version 2.2-SNAPSHOT does not
> suffer from the same problem.
--
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] (MJAR-139) New option to avoid empty jar creation
[ https://jira.codehaus.org/browse/MJAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MJAR-139. --- Resolution: Fixed Fix Version/s: 2.4 Assignee: Kristian Rosenvold Patch applied in r1235468, thanks for the patch! Added IT > New option to avoid empty jar creation > -- > > Key: MJAR-139 > URL: https://jira.codehaus.org/browse/MJAR-139 > Project: Maven 2.x JAR Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 >Reporter: Roman Ivanov >Assignee: Kristian Rosenvold > Fix For: 2.4 > > Attachments: MJAR-139.patch > > > Usage of "test-jar" is beneficial for all project, as all of them have tests. > > org.apache.maven.plugins > maven-jar-plugin > 2.3.1 > > > > test-jar > > > > > Pom artifacts and some jar artifacts does not have test and will never have > them. > In logs we have: "[WARNING] JAR will be empty - no content was marked for > inclusion!" > and empty and useless artifacts are created, deployed , ... > It will be convenient to have an plugin option to define whether skip empty > jar creation and warning or generate jar with warning in log. Does it make > sense ? > By default option will be FALSE, to comply with previous behavior. -- 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] (MWAR-273) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MWAR-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MWAR-273. Resolution: Fixed Fix Version/s: 2.1.2 Assignee: Dennis Lundberg > Add Maven version used to Created-By entry in manifest > -- > > Key: MWAR-273 > URL: https://jira.codehaus.org/browse/MWAR-273 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement >Affects Versions: 2.1.1 > Environment: n/a >Reporter: Anders Hammar >Assignee: Dennis Lundberg > Fix For: 2.1.2 > > Attachments: MWAR-273.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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] (MRESOURCES-144) if filter file does not exist it should optionally ignore it, not just throw an exception
[
https://jira.codehaus.org/browse/MRESOURCES-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289560#comment-289560
]
Suresh Avadhanula commented on MRESOURCES-144:
--
By default maven-filtering-1.0-beta4 seems to pulled by maven resources plugin.
I have maven 3.0.3.
I applied the patch to maven-filtering module. Update the pom to use the right
version of the filtering module.
org.apache.maven.plugins
maven-resources-plugin
2.5
org.apache.maven.shared
maven-filtering
1.0
generate-resources
resources
> if filter file does not exist it should optionally ignore it, not just throw
> an exception
> -
>
> Key: MRESOURCES-144
> URL: https://jira.codehaus.org/browse/MRESOURCES-144
> Project: Maven 2.x Resources Plugin
> Issue Type: Improvement
>Affects Versions: 2.4.3
>Reporter: richard stevenson
>Assignee: Olivier Lamy
>Priority: Minor
> Attachments: maven-filter.patch
>
>
> If you have a list of filter files
>
> a.properties
> b.properties
> ${prop.name}.properties
>
> It would be nice to tell the resources plugin to optioanlly ignore a file if
> it does not exist. Currently get the following stack trace:
> org.apache.maven.lifecycle.LifecycleExecutionException: Error loading
> property f
> ile 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
> 0)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error loading
> propert
> y file 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:269)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Error
> load
> ing property file 'D:\projects\.../src/main/filters/a.properties'
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:274)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFi
> lterWrappers(DefaultMavenFileFilter.java:199)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filt
> erReso
[jira] (MRESOURCES-144) if filter file does not exist it should optionally ignore it, not just throw an exception
[
https://jira.codehaus.org/browse/MRESOURCES-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suresh Avadhanula updated MRESOURCES-144:
-
Attachment: maven-filter.patch
Warns about missing property file. Throws exception if and only if all of the
property files are missing
> if filter file does not exist it should optionally ignore it, not just throw
> an exception
> -
>
> Key: MRESOURCES-144
> URL: https://jira.codehaus.org/browse/MRESOURCES-144
> Project: Maven 2.x Resources Plugin
> Issue Type: Improvement
>Affects Versions: 2.4.3
>Reporter: richard stevenson
>Assignee: Olivier Lamy
>Priority: Minor
> Attachments: maven-filter.patch
>
>
> If you have a list of filter files
>
> a.properties
> b.properties
> ${prop.name}.properties
>
> It would be nice to tell the resources plugin to optioanlly ignore a file if
> it does not exist. Currently get the following stack trace:
> org.apache.maven.lifecycle.LifecycleExecutionException: Error loading
> property f
> ile 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
> 0)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error loading
> propert
> y file 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:269)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Error
> load
> ing property file 'D:\projects\.../src/main/filters/a.properties'
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:274)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFi
> lterWrappers(DefaultMavenFileFilter.java:199)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filt
> erResources(DefaultMavenResourcesFiltering.java:162)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:265)
> ... 19 more
> Caused by: java.io.FileNotFoundException:
> D:\projects\.../src/main/filters/a.fil
> ter.properties
> at
> org.apache.maven.shared.filtering.PropertyUtils.loadPropertyFile(Prop
> ertyUtils.java:65)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:269)
> ... 22 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289558#comment-289558
]
John Casey edited comment on SUREFIRE-809 at 1/24/12 1:36 PM:
--
Applied in revIds: 1235412-1235416
All existing tests are passing; now I need to add a few new tests to verify the
extra expression combination features.
BTW, the mechanisms used to introduce these matchers into JUnit and TestNG are:
*JUnit:*
Modified FilterFactory to parse the group expressions, combine them into a
single matcher object (with the excludes matcher section inverted). Then,
wrapped the matcher in a JUnit Filter implementation, and passed back in place
of the old comma-separated listing of Filter instances.
*TestNG:*
Modified AbstractDirectConfigurator to parse group expressions in much the same
way as above (with JUnit), then set the matcher instance STATICALLY on a new
IMethodSelector implementation. This static setter is my workaround for the
fact that TestNG classloads / instantiates method selectors, rather than
allowing instances to be injected directly. I didn't want to use a file-based
approach, in case multiple TestNG processes ran simultaneously in a build (the
selector would have to know the file name). The old groups / excludeGroups
settings are commented out in favor of the new method selector.
These implementations may be controversial / flawed. If so, please provide some
guidance as to a preferred alternative mechanism, since I'm relatively
unfamiliar with the deep workings of these test frameworks.
was (Author: jdcasey):
Applied in revIds: 1235412-1235416
All existing tests are passing; now I need to add a few new tests to verify the
extra expression combination features.
BTW, the mechanisms used to introduce these matchers into JUnit and TestNG are:
JUnit: Modified FilterFactory to parse the group expressions, combine them into
a single matcher object (with the excludes matcher section inverted). Then,
wrapped the matcher in a JUnit Filter implementation, and passed back in place
of the old comma-separated listing of Filter instances.
TestNG: Modified AbstractDirectConfigurator to parse group expressions in much
the same way as above (with JUnit), then set the matcher instance STATICALLY on
a new IMethodSelector implementation. This static setter is my workaround for
the fact that TestNG classloads / instantiates method selectors, rather than
allowing instances to be injected directly. I didn't want to use a file-based
approach, in case multiple TestNG processes ran simultaneously in a build (the
selector would have to know the file name). The old groups / excludeGroups
settings are commented out in favor of the new method selector.
These implementations may be controversial / flawed. If so, please provide some
guidance as to a preferred alternative mechanism, since I'm relatively
unfamiliar with the deep workings of these test frameworks.
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289558#comment-289558
]
John Casey edited comment on SUREFIRE-809 at 1/24/12 1:35 PM:
--
Applied in revIds: 1235412-1235416
All existing tests are passing; now I need to add a few new tests to verify the
extra expression combination features.
BTW, the mechanisms used to introduce these matchers into JUnit and TestNG are:
JUnit: Modified FilterFactory to parse the group expressions, combine them into
a single matcher object (with the excludes matcher section inverted). Then,
wrapped the matcher in a JUnit Filter implementation, and passed back in place
of the old comma-separated listing of Filter instances.
TestNG: Modified AbstractDirectConfigurator to parse group expressions in much
the same way as above (with JUnit), then set the matcher instance STATICALLY on
a new IMethodSelector implementation. This static setter is my workaround for
the fact that TestNG classloads / instantiates method selectors, rather than
allowing instances to be injected directly. I didn't want to use a file-based
approach, in case multiple TestNG processes ran simultaneously in a build (the
selector would have to know the file name). The old groups / excludeGroups
settings are commented out in favor of the new method selector.
These implementations may be controversial / flawed. If so, please provide some
guidance as to a preferred alternative mechanism, since I'm relatively
unfamiliar with the deep workings of these test frameworks.
was (Author: jdcasey):
Applied in revIds: 1235412-1235416
All existing tests are passing; now I need to add a few new tests to verify the
extra expression combination features.
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289558#comment-289558
]
John Casey commented on SUREFIRE-809:
-
Applied in revIds: 1235412-1235416
All existing tests are passing; now I need to add a few new tests to verify the
extra expression combination features.
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
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] (MJAR-69) When 'index' and 'addClasspath' are both true, plugin fails.
[
https://jira.codehaus.org/browse/MJAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MJAR-69:
---
Fix Version/s: 2.4
Assignee: Kristian Rosenvold
This issue is fixed by updating plexus components to their latest versions.
> When 'index' and 'addClasspath' are both true, plugin fails.
>
>
> Key: MJAR-69
> URL: https://jira.codehaus.org/browse/MJAR-69
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Anagnostopoulos Kostis
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: trace.log
>
>
> When both the 'index' and 'addClasspath' are true, the plugin fails to create
> jar with the following msg:
> Embedded error: Problem creating jar: **/target/classes (Is a directory)
> A typical configuration to produce the error would be:
> {code:xml}
>
> maven-jar-plugin
>
>
> true
>
> true
>
>
>
> {code}
> The issue below (about including dependency files in index) claims that it
> introduced this bug:
> http://jira.codehaus.org/browse/MJAR-40
> I'm posting this issue so that to ensure that version 2.2-SNAPSHOT does not
> suffer from the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289548#comment-289548 ] nkeywal commented on SUREFIRE-799: -- Kristian renamed it to "perthread" in the trunk. It works well for us. > Allow test parallelisation when forkMode=always > --- > > Key: SUREFIRE-799 > URL: https://jira.codehaus.org/browse/SUREFIRE-799 > Project: Maven Surefire > Issue Type: Improvement > Components: process forking >Affects Versions: 2.10 > Environment: all >Reporter: nkeywal >Assignee: Kristian Rosenvold > Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch > > > Surefire already allows: > - forking > - parallelization within a JVM > Mixing both features would mean forking multiple JVM instead of only one. > It would allow to parallelize tests that need to be executed in a separate > JVM (i.e.: with forkMode=always). Usually these tests take longer than the > simple ones. In our case, 40% of the tests are executed in 4 minutes, the > other 60% need two hours. So it's obviously more interesting to parallelize > the former, but these ones need to fork. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289546#comment-289546 ] Alexey Yudichev commented on SUREFIRE-799: -- This is not yet in https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/2.12-SNAPSHOT/maven-surefire-plugin-2.12-20120119.191905-28.jar by the looks of it as I'm getting: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.12-SNAPSHOT:test failed: Fork mode perThread is not a legal value Any chance you can deploy a snapshot with this patch in? > Allow test parallelisation when forkMode=always > --- > > Key: SUREFIRE-799 > URL: https://jira.codehaus.org/browse/SUREFIRE-799 > Project: Maven Surefire > Issue Type: Improvement > Components: process forking >Affects Versions: 2.10 > Environment: all >Reporter: nkeywal >Assignee: Kristian Rosenvold > Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch > > > Surefire already allows: > - forking > - parallelization within a JVM > Mixing both features would mean forking multiple JVM instead of only one. > It would allow to parallelize tests that need to be executed in a separate > JVM (i.e.: with forkMode=always). Usually these tests take longer than the > simple ones. In our case, 40% of the tests are executed in 4 minutes, the > other 60% need two hours. So it's obviously more interesting to parallelize > the former, but these ones need to fork. -- 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-588) Build fails because of 'ls -1nlaR /'
[ https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-588: - Fix Version/s: 2.3 Assignee: Kristian Rosenvold > Build fails because of 'ls -1nlaR /' > > > Key: MASSEMBLY-588 > URL: https://jira.codehaus.org/browse/MASSEMBLY-588 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: Ubuntu 11.10 (oneiric) >Reporter: Thomas Pasch >Assignee: Kristian Rosenvold > Fix For: 2.3 > > Attachments: partial_log.bz2 > > > This is a report again > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) used in conjunction with maven 3.0.3. I'm trying to build > ebml-viewer from svn r126 (lastest) at > http://code.google.com/p/ebml-viewer/source/checkout . Build fails on Linux, > but the developer of ebml-viewer reports that it builds fine on Windows. > Last lines of output from failed build with 'mvn -DskipTests -X -e package > 2>&1 | tee log': > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2:37.924s > [INFO] Finished at: Tue Dec 06 20:30:47 CET 2011 > [INFO] Final Memory: 8M/216M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > 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:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error creating assembly archive bin: Failed to retrieve numeric > file attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:504) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error creating assembly archive bin: Failed to retrieve numeric file > attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:189) > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:445) > ... 21 more > Caused by: org.codehaus.plexus.archiver.ArchiverException: Failed to retriev
[jira] (MASSEMBLY-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
[
https://jira.codehaus.org/browse/MASSEMBLY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MASSEMBLY-595:
-
Fix Version/s: 2.3
Assignee: Kristian Rosenvold
Will be upgrading to maven-archiver 2.5 and plexus-archiver 2.1 when releasing.
Please note the patch in plexus-archiver 2.0.2 is buggy and cannot be used.
> Tar file contains world-writeable files when fileSets with and without
> fileMode are mixed
> -
>
> Key: MASSEMBLY-595
> URL: https://jira.codehaus.org/browse/MASSEMBLY-595
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Joseph Walton
>Assignee: Kristian Rosenvold
> Fix For: 2.3
>
> Attachments:
> 0001-MASSEMBLY-595-Upgrade-to-pick-up-PLXCOMP-196-and-PLX.patch,
> MASSEMBLY-595.tar.gz
>
>
> I have an assembly descriptor with some fileSets that do and some that don't
> set the fileMode. Any resources after fileMode has been set end up with
> world-writable permissions.
> This assembly descriptor:
> {code}
>
> dist
>
> tar.gz
>
>
>
> src/main/files
> a
>
>
> src/main/files
> b
> 0744
>
>
> src/main/files
> c
>
>
>
> {code}
> gives:
> {code}
> $ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
> drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
> -rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
> drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
> -rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
> drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
> -rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
> {code}
> The third copy of the fileSet, with no {{fileMode}} set, is now
> world-writable, unlike the first. The second directory, with no
> {{directoryMode}} specified, has the same problem.
--
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] (MSHARED-182) manifestEntry seems not to work correctly
[
https://jira.codehaus.org/browse/MSHARED-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MSHARED-182.
--
Resolution: Fixed
Fix Version/s: maven-archiver-2.5
Assignee: Kristian Rosenvold
Testcase added in r1235291, seems to work fine. Probably due to manifest change
in plexus-archiver
> manifestEntry seems not to work correctly
> -
>
> Key: MSHARED-182
> URL: https://jira.codehaus.org/browse/MSHARED-182
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
> Environment: maven-jar-plugin 2.3.1
>Reporter: Rolf Schumacher
>Assignee: Kristian Rosenvold
>Priority: Blocker
> Fix For: maven-archiver-2.5
>
>
> hope this is the correct place ot file an issue about maven-jar-plugin
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
> 2.3.1
>
>
>
> true
> eu.ngong.xslt.App
> /usr/share/java/
>
>
> xxx
> yyy
>
>
>
>
> {code}
> does not work: silently neither a classpass is generated nor the requested
> entries Name and Content-Type.
> If I exchange the manifestEntries by
> {code:xml}
>
> value
>
> {code}
> it works: the classpath is generated in MANIFEST.MF as well as the "key:
> value" line.
> If I exchange the manifestEntries by
> {code:xml}
>
> value
>
> {code}
> it does not work: the classpath is generated but not the "Key: value" line.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-134) Using ${artifcactId}-Extention-Name in MANIFEST file can create invalid MANIFEST files
[
https://jira.codehaus.org/browse/MSHARED-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MSHARED-134.
--
Resolution: Fixed
Fix Version/s: maven-archiver-2.5
Assignee: Kristian Rosenvold
Fixed with testcase in r1235286
> Using ${artifcactId}-Extention-Name in MANIFEST file can create invalid
> MANIFEST files
> --
>
> Key: MSHARED-134
> URL: https://jira.codehaus.org/browse/MSHARED-134
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-2.4
> Environment: Java HotSpot(TM) Client VM (build 1.5.0_13-121)
>Reporter: Todd Caine
>Assignee: Kristian Rosenvold
> Fix For: maven-archiver-2.5
>
> Attachments: MavenArchiver.java-Patch.txt, nautilus-debug-log.txt
>
>
> If you have a maven dependency on an something with an artifactId that
> contains a '.' in it, it creates an illegal manifest file when trying to
> create an executable jar file (java -jar foo.jar).
> {noformat}
> Exception in thread "main" java.io.IOException: invalid header field name:
> geronimo-jms_1.1_spec-Extension-Name
> at java.util.jar.Attributes.read(Attributes.java:409)
> at java.util.jar.Manifest.read(Manifest.java:167)
> at java.util.jar.Manifest.(Manifest.java:52)
> at java.util.jar.JarFile.getManifestFromReference(JarFile.java:158)
> at java.util.jar.JarFile.getManifest(JarFile.java:145)
> {noformat}
> Here's my configuration:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> my.class.Test
> true
> true
> ./lib/
>
>
>
>
> {code}
> I added the following dependency:
> {code:xml}
>
> org.apache.geronimo.specs
> geronimo-jms_1.1_spec
>
> {code}
> When the maven-archiver tries to create a manifest file with the JARs
> dependencies it adds the following to the META-INF/MANIFEST.MF file:
> {noformat}
> geronimo-jms_1.1_spec-Extension-Name: geronimo-jms_1.1_spec
> geronimo-jms_1.1_spec-Implementation-Version: 1.0
> {noformat}
> After digging around a bit it turns out that '.' is an illegal character in
> the "Extension-Name" and "Implementaion-Version" header fields, which leads
> to the following exception when I try to run "java -jar Test.jar"
> java.io.IOException: invalid header field name:
> geronimo-jms_1.1_spec-Extension-Name
--
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-343) Add "skip" parameter for copy-dependencies
Denis created MDEP-343: -- Summary: Add "skip" parameter for copy-dependencies Key: MDEP-343 URL: https://jira.codehaus.org/browse/MDEP-343 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: copy-dependencies Affects Versions: 2.4 Reporter: Denis It would be nice if the "copy-dependencies" goal could be skipped by defining a parameter "skip" (just like you can do within the copy goal configuration) -- 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] (MEAR-145) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEAR-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MEAR-145: --- Attachment: MEAR-145.patch Attached patch. The version of maven-archiver needs to be updated to 2.5 once released. > Add Maven version used to Created-By entry in manifest > -- > > Key: MEAR-145 > URL: https://jira.codehaus.org/browse/MEAR-145 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: n/a >Reporter: Anders Hammar > Attachments: MEAR-145.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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] (MEAR-60) Improve support for skinny war files
[
https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289261#comment-289261
]
Andreas Thaler commented on MEAR-60:
I configured the outputFileNameMapping for the war-plugin like that:
{code}
org.apache.maven.plugins
maven-war-plugin
2.1.1
@{artifactId}@-@{baseVersion}@.@{extension}@
{code}
> Improve support for skinny war files
>
>
> Key: MEAR-60
> URL: https://jira.codehaus.org/browse/MEAR-60
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.3
> Environment: mvn 2.0.5
>Reporter: Marcel Schutte
>Assignee: Dennis Lundberg
>Priority: Critical
> Fix For: 2.7
>
> Attachments: maven-ear-plugin-addon-1.0-SNAPSHOT.jar,
> maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar,
> maven-ear-plugin-MEAR-60.patch
>
>
> Provide a boolean configuration option for webModules to include the war's
> transitive dependencies.
> As described on
> http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it
> is very common in a J2EE environment to use so called skinny wars. Here the
> war's WEB-INF/lib will not contain the dependent jars, but instead they are
> packaged inside the EAR. The war references them through its
> META-INF/MANIFEST.MF
> This option could be used to avoid the 'painful part' mentioned in the above
> web page. The war's dependencies wouldn't have to be duplicated alongside the
> ear's.
> I also found an old issue (MEAR-14) which has asked for the current default
> behavior of not including the transitive dependencies. It suggests a property
> to include specific dependencies of the war. As far as I can tell this has
> never been implemented and this is also not what I am asking for. My proposal
> is an all of nothing kind of option for each war module in the ear.
> On a side note, for me this is the part where removal of the old maven 1
> style properties per dependency is missed the most. With them it was possible
> to decide for each single dependency whether to put it in WEB-INF/lib or
> reference it through the manifest classpath. But of course, then we didn't
> have the transitive dependencies
--
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-628) Format of report goal names for /project/menu/item/@ref not properly documented
Andreas Sewe created MSITE-628:
--
Summary: Format of report goal names for /project/menu/item/@ref
not properly documented
Key: MSITE-628
URL: https://jira.codehaus.org/browse/MSITE-628
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Improvement
Components: documentation
Affects Versions: 3.0
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Reporter: Andreas Sewe
Priority: Minor
This is probably just a documentation issue rather than a bug: I am unable
(using Maven 3.0.4, {{maven-site-plugin}} 3.0) to set
{{/project/menu/item/@ref}} such that the plugin actually recognizes the
reference:
{quote}
[WARNING] Unrecognised reference: 'project-info-reports:mailing-list'
{quote}
(Also, just {{mailing-list}} and
{{maven-project-info-reports-plugin:mailing-list}} won't work either.)
The documentation in the XML Schema is unfortunately not very helpful:
{quote}
A reference to a pre-defined menu item, such as a report (specified by the
report goal name). Any elements explicitly given override those from the
pre-defined reference.
{quote}
An example showing the proper _report goal name_ format would thus be a helpful
addition to the XML Schema.
--
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-26) hard coded style with padding-top for body
Olivier Lamy created MSKINS-26:
--
Summary: hard coded style with padding-top for body
Key: MSKINS-26
URL: https://jira.codehaus.org/browse/MSKINS-26
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-1.0
Reporter: Olivier Lamy
there is an hardcoded
{code:xml}
body{padding-top: 20px;}
{code}
It's impossible to not have it generated
--
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] (MSHARED-99) Archiver should validate manifest attribute names.
[ https://jira.codehaus.org/browse/MSHARED-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MSHARED-99. - Resolution: Fixed Fix Version/s: maven-archiver-2.5 Assignee: Kristian Rosenvold Plexus-archiver 2.1 uses the jdk manifest class, which barfs loudly about illegal attributes > Archiver should validate manifest attribute names. > -- > > Key: MSHARED-99 > URL: https://jira.codehaus.org/browse/MSHARED-99 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-archiver >Reporter: Paul Gier >Assignee: Kristian Rosenvold >Priority: Minor > Fix For: maven-archiver-2.5 > > > I noticed that the jar plugin and maven archiver will allow you to use an > invalid attribute name in your manifest. According the jar specification, > attribute names can only contain letters, numbers, dash, or underscore [1]. > Currently if you put an attribute name like "my.attribute" in the manifest > configuration of the jar plugin, the attribute will be added to your jar > manifest. If you then try to use this jar file in your classpath, for > example as a dependency of another project, you will get a compilation error: > [INFO] Compilation failure > error: error reading > /home/me/.m2/repository/org/company/my-project/1.0-SNAPSHOT/my-project-1.0-SNAPSHOT.jar; > invalid header field name: my.attribute > The archiver or the jar plugin should do a regex check to make sure that you > are using a valid attribute name. And if not, a warning or error should be > produced. > [1] > http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Name-Value%20pairs%20and%20Sections -- 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] (MSHARED-210) Maven2OsgiConverter provide simple mechanism for more than 3 version part conversion
[
https://jira.codehaus.org/browse/MSHARED-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MSHARED-210:
---
Component/s: maven-osgi
> Maven2OsgiConverter provide simple mechanism for more than 3 version part
> conversion
>
>
> Key: MSHARED-210
> URL: https://jira.codehaus.org/browse/MSHARED-210
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-osgi
>Reporter: Darryl L. Miles
>
> At the moment the default Maven2OsgiConverter implementation truncates the
> version number after the 3rd part.
> 1.2.3.4.5.20111019-SNAPSHOT => 1.2.3.SNAPSHOT
> This request is to provide a mechanism to allow a fully numeric part to be
> padded with leading zeros like:
> 1.2.3.4.5.20111019-SNAPSHOT => 1.2.00300400520111019.SNAPSHOT
> 1.2.20111019-SNAPSHOT => 1.2.20111019.SNAPSHOT
> 1.2.3.20111019-SNAPSHOT => 1.2.00320111019.SNAPSHOT
> The only option the user needs to supply in configuration is the number of
> places to pad it out to, if the part is already that long (or longer) then no
> extra padding is added. Maybe the default is 3 (or an automatic default of).
> I think this kind of conversion should be an option built into the stock
> Maven/OSGi integration, you are converting a valid Maven version number into
> a valid OSGi version number and providing a mechanism to loose the least
> amount of precision of information.
> A really nice to have feature would be an option to specify a formatter
> %{03:1}.%{2}.%{06:3} where all padding presumes leading zeros (never spaces),
> where is uses some other Java convention for String formatting, where the
> output must have no more than 3 full-stop characters in it (and other
> validation fules). So a sub-set of String formatter rules but allowing total
> control. Any parts not conforming to the rules would cause plugin build
> failure and suitable conversion error.
--
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-730) release:prepare cannot find dependent artefact
[
https://jira.codehaus.org/browse/MRELEASE-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289253#comment-289253
]
Thomas Diesler edited comment on MRELEASE-730 at 1/24/12 4:57 AM:
--
The parent pom defines
{code}
jboss-releases-repository
JBoss Releases Repository
${jboss.releases.repo.url}
jboss-snapshots-repository
JBoss Snapshots Repository
${jboss.snapshots.repo.url}
{code}
You can test with
https://github.com/jbosgi/jbosgi-resolver/commit/713618aeaabdb71dd3f98191a0c642f108a786ae
was (Author: tdiesler):
The parent pom defines
{code}
jboss-releases-repository
JBoss Releases Repository
${jboss.releases.repo.url}
jboss-snapshots-repository
JBoss Snapshots Repository
${jboss.snapshots.repo.url}
{code}
> release:prepare cannot find dependent artefact
> --
>
> Key: MRELEASE-730
> URL: https://jira.codehaus.org/browse/MRELEASE-730
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.2.2
>Reporter: Thomas Diesler
>
> It seems that release:prepare assumes dependencies to come from central
> {code}
> [tdiesler@tdvaio jbosgi-resolver]$ mvn release:prepare
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] JBossOSGi Resolver
> [INFO] JBossOSGi Resolver API
> [INFO] JBossOSGi Resolver Felix
> [INFO]
>
> [INFO]
>
> [INFO] Building JBossOSGi Resolver 2.0.0.Alpha5-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @
> jbosgi-resolver-parent ---
> [INFO] Verifying that there are no local modifications...
> [INFO] ignoring changes on: pom.xml.next, release.properties,
> pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
> [INFO] Executing: /bin/sh -c cd /home/tdiesler/git/jbosgi-resolver && git
> status
> [INFO] Working directory: /home/tdiesler/git/jbosgi-resolver
> [INFO] Checking dependencies and plugins for snapshots ...
> What is the release version for "JBossOSGi Resolver"?
> (org.jboss.osgi.resolver:jbosgi-resolver-parent) 2.0.0.Alpha5: :
> What is the release version for "JBossOSGi Resolver API"?
> (org.jboss.osgi.resolver:jbosgi-resolver-apiv2) 2.0.0.Alpha5: :
> What is the release version for "JBossOSGi Resolver Felix"?
> (org.jboss.osgi.resolver:jbosgi-resolver-felix) 2.0.0.Alpha5: :
> What is SCM release tag or label for "JBossOSGi Resolver"?
> (org.jboss.osgi.resolver:jbosgi-resolver-parent)
> jbosgi-resolver-parent-2.0.0.Alpha5: :
> What is the new development version for "JBossOSGi Resolver"?
> (org.jboss.osgi.resolver:jbosgi-resolver-parent) 2.0.1.Alpha5-SNAPSHOT: :
> What is the new development version for "JBossOSGi Resolver API"?
> (org.jboss.osgi.resolver:jbosgi-resolver-apiv2) 2.0.1.Alpha5-SNAPSHOT: :
> What is the new development version for "JBossOSGi Resolver Felix"?
> (org.jboss.osgi.resolver:jbosgi-resolver-felix) 2.0.1.Alpha5-SNAPSHOT: :
> [INFO] Transforming 'JBossOSGi Resolver'...
> [INFO] Transforming 'JBossOSGi Resolver API'...
> [INFO] Transforming 'JBossOSGi Resolver Felix'...
> [INFO] Ignoring artifact version update for expression ${project.version}
> [INFO] Not generating release POMs
> [INFO] Executing goals 'clean verify'...
> [WARNING] Maven will be executed in interactive mode, but no input stream has
> been configured for this MavenInvoker instance.
> [INFO] [INFO] Scanning for projects...
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Build Order:
> [INFO] [INFO]
> [INFO] [INFO] JBossOSGi Resolver
> [INFO] [INFO] JBossOSGi Resolver API
> [INFO] [INFO] JBossOSGi Resolver Felix
> [INFO] [INFO]
>
> [INFO] [INFO]
>
> [INFO] [INFO] Building JBossOSGi Resolver 2.0.0.Alpha5
> [INFO] [INFO]
>
> [INFO] [INFO]
> [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> jbosgi-resolver-parent ---
> [INFO] [INFO] Deleting /home/tdiesler/git/jbosgi-resolver/target
> [INFO] [INFO]
> [INFO] [INFO] >>> maven-sourc
[jira] (MRELEASE-730) release:prepare cannot find dependent artefact
[
https://jira.codehaus.org/browse/MRELEASE-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289253#comment-289253
]
Thomas Diesler commented on MRELEASE-730:
-
The parent pom defines
{code}
jboss-releases-repository
JBoss Releases Repository
${jboss.releases.repo.url}
jboss-snapshots-repository
JBoss Snapshots Repository
${jboss.snapshots.repo.url}
{code}
> release:prepare cannot find dependent artefact
> --
>
> Key: MRELEASE-730
> URL: https://jira.codehaus.org/browse/MRELEASE-730
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.2.2
>Reporter: Thomas Diesler
>
> It seems that release:prepare assumes dependencies to come from central
> {code}
> [tdiesler@tdvaio jbosgi-resolver]$ mvn release:prepare
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] JBossOSGi Resolver
> [INFO] JBossOSGi Resolver API
> [INFO] JBossOSGi Resolver Felix
> [INFO]
>
> [INFO]
>
> [INFO] Building JBossOSGi Resolver 2.0.0.Alpha5-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @
> jbosgi-resolver-parent ---
> [INFO] Verifying that there are no local modifications...
> [INFO] ignoring changes on: pom.xml.next, release.properties,
> pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
> [INFO] Executing: /bin/sh -c cd /home/tdiesler/git/jbosgi-resolver && git
> status
> [INFO] Working directory: /home/tdiesler/git/jbosgi-resolver
> [INFO] Checking dependencies and plugins for snapshots ...
> What is the release version for "JBossOSGi Resolver"?
> (org.jboss.osgi.resolver:jbosgi-resolver-parent) 2.0.0.Alpha5: :
> What is the release version for "JBossOSGi Resolver API"?
> (org.jboss.osgi.resolver:jbosgi-resolver-apiv2) 2.0.0.Alpha5: :
> What is the release version for "JBossOSGi Resolver Felix"?
> (org.jboss.osgi.resolver:jbosgi-resolver-felix) 2.0.0.Alpha5: :
> What is SCM release tag or label for "JBossOSGi Resolver"?
> (org.jboss.osgi.resolver:jbosgi-resolver-parent)
> jbosgi-resolver-parent-2.0.0.Alpha5: :
> What is the new development version for "JBossOSGi Resolver"?
> (org.jboss.osgi.resolver:jbosgi-resolver-parent) 2.0.1.Alpha5-SNAPSHOT: :
> What is the new development version for "JBossOSGi Resolver API"?
> (org.jboss.osgi.resolver:jbosgi-resolver-apiv2) 2.0.1.Alpha5-SNAPSHOT: :
> What is the new development version for "JBossOSGi Resolver Felix"?
> (org.jboss.osgi.resolver:jbosgi-resolver-felix) 2.0.1.Alpha5-SNAPSHOT: :
> [INFO] Transforming 'JBossOSGi Resolver'...
> [INFO] Transforming 'JBossOSGi Resolver API'...
> [INFO] Transforming 'JBossOSGi Resolver Felix'...
> [INFO] Ignoring artifact version update for expression ${project.version}
> [INFO] Not generating release POMs
> [INFO] Executing goals 'clean verify'...
> [WARNING] Maven will be executed in interactive mode, but no input stream has
> been configured for this MavenInvoker instance.
> [INFO] [INFO] Scanning for projects...
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Build Order:
> [INFO] [INFO]
> [INFO] [INFO] JBossOSGi Resolver
> [INFO] [INFO] JBossOSGi Resolver API
> [INFO] [INFO] JBossOSGi Resolver Felix
> [INFO] [INFO]
>
> [INFO] [INFO]
>
> [INFO] [INFO] Building JBossOSGi Resolver 2.0.0.Alpha5
> [INFO] [INFO]
>
> [INFO] [INFO]
> [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> jbosgi-resolver-parent ---
> [INFO] [INFO] Deleting /home/tdiesler/git/jbosgi-resolver/target
> [INFO] [INFO]
> [INFO] [INFO] >>> maven-source-plugin:2.1.2:jar (attach-sources) @
> jbosgi-resolver-parent >>>
> [INFO] [INFO]
> [INFO] [INFO] <<< maven-source-plugin:2.1.2:jar (attach-sources) @
> jbosgi-resolver-parent <<<
> [INFO] [INFO]
> [INFO] [INFO] --- maven-source-plugin:2.1.2:jar (attach-sources) @
> jbosgi-resolver-parent ---
> [INFO] [INFO]
>
> [INFO] [INFO]
>
> [INFO] [INFO] Building JBossOSGi Resolver API 2.
[jira] (MRELEASE-730) release:prepare cannot find dependent artefact
Thomas Diesler created MRELEASE-730:
---
Summary: release:prepare cannot find dependent artefact
Key: MRELEASE-730
URL: https://jira.codehaus.org/browse/MRELEASE-730
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Thomas Diesler
It seems that release:prepare assumes dependencies to come from central
{code}
[tdiesler@tdvaio jbosgi-resolver]$ mvn release:prepare
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] JBossOSGi Resolver
[INFO] JBossOSGi Resolver API
[INFO] JBossOSGi Resolver Felix
[INFO]
[INFO]
[INFO] Building JBossOSGi Resolver 2.0.0.Alpha5-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @
jbosgi-resolver-parent ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: pom.xml.next, release.properties,
pom.xml.releaseBackup, pom.xml.backup, pom.xml.branch, pom.xml.tag
[INFO] Executing: /bin/sh -c cd /home/tdiesler/git/jbosgi-resolver && git status
[INFO] Working directory: /home/tdiesler/git/jbosgi-resolver
[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for "JBossOSGi Resolver"?
(org.jboss.osgi.resolver:jbosgi-resolver-parent) 2.0.0.Alpha5: :
What is the release version for "JBossOSGi Resolver API"?
(org.jboss.osgi.resolver:jbosgi-resolver-apiv2) 2.0.0.Alpha5: :
What is the release version for "JBossOSGi Resolver Felix"?
(org.jboss.osgi.resolver:jbosgi-resolver-felix) 2.0.0.Alpha5: :
What is SCM release tag or label for "JBossOSGi Resolver"?
(org.jboss.osgi.resolver:jbosgi-resolver-parent)
jbosgi-resolver-parent-2.0.0.Alpha5: :
What is the new development version for "JBossOSGi Resolver"?
(org.jboss.osgi.resolver:jbosgi-resolver-parent) 2.0.1.Alpha5-SNAPSHOT: :
What is the new development version for "JBossOSGi Resolver API"?
(org.jboss.osgi.resolver:jbosgi-resolver-apiv2) 2.0.1.Alpha5-SNAPSHOT: :
What is the new development version for "JBossOSGi Resolver Felix"?
(org.jboss.osgi.resolver:jbosgi-resolver-felix) 2.0.1.Alpha5-SNAPSHOT: :
[INFO] Transforming 'JBossOSGi Resolver'...
[INFO] Transforming 'JBossOSGi Resolver API'...
[INFO] Transforming 'JBossOSGi Resolver Felix'...
[INFO] Ignoring artifact version update for expression ${project.version}
[INFO] Not generating release POMs
[INFO] Executing goals 'clean verify'...
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.
[INFO] [INFO] Scanning for projects...
[INFO] [INFO]
[INFO] [INFO] Reactor Build Order:
[INFO] [INFO]
[INFO] [INFO] JBossOSGi Resolver
[INFO] [INFO] JBossOSGi Resolver API
[INFO] [INFO] JBossOSGi Resolver Felix
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] Building JBossOSGi Resolver 2.0.0.Alpha5
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
jbosgi-resolver-parent ---
[INFO] [INFO] Deleting /home/tdiesler/git/jbosgi-resolver/target
[INFO] [INFO]
[INFO] [INFO] >>> maven-source-plugin:2.1.2:jar (attach-sources) @
jbosgi-resolver-parent >>>
[INFO] [INFO]
[INFO] [INFO] <<< maven-source-plugin:2.1.2:jar (attach-sources) @
jbosgi-resolver-parent <<<
[INFO] [INFO]
[INFO] [INFO] --- maven-source-plugin:2.1.2:jar (attach-sources) @
jbosgi-resolver-parent ---
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] Building JBossOSGi Resolver API 2.0.0.Alpha5
[INFO] [INFO]
[INFO] Downloading:
http://repo1.maven.org/maven2/org/jboss/osgi/vfs/jbosgi-vfs30/1.0.6/jbosgi-vfs30-1.0.6.pom
[INFO]
[INFO] [WARNING] The POM for org.jboss.osgi.vfs:jbosgi-vfs30:jar:1.0.6 is
missing, no dependency information available
[INFO] Downloading:
http://repo1.maven.org/maven2/org/jboss/osgi/vfs/jbosgi-vfs30/1.0.6/jbosgi-vfs30-1.0.6.jar
[INFO]
[INFO] [INFO]
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] JBossOSGi Resolver SUCCESS
[1.276s]
[INFO] [INFO] JBossOSGi Resolver API ..
[jira] (MWAR-257) dependentWarExcludes is deprecated but
[ https://jira.codehaus.org/browse/MWAR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289245#comment-289245 ] Joerg Schaible commented on MWAR-257: - The deprecation should be simply reverted. Even the plugin overlay documentation (http://maven.apache.org/plugins/maven-war-plugin/overlays.html) explicitly refers dependentWarExcludes and dependentWarIncludes as *the only* possibility to make global settings in a plugin management section that is inherited in multiple projects. There is no equivalent possible with overlays/overlay/excludes or overlays/overlay/includes and actually it is also not necessary to introduce something else for a mechanism that is working properly. > dependentWarExcludes is deprecated but > --- > > Key: MWAR-257 > URL: https://jira.codehaus.org/browse/MWAR-257 > Project: Maven 2.x WAR Plugin > Issue Type: Bug > Components: overlay >Affects Versions: 2.1.1 >Reporter: dool > > Hello, > DependentWarExcludes is marked as deprecated. Documentation says to use > / instead. > But it seems to me that it is not possible to get the same behaviour with > / as in this case we have to provide groupIds and > artifactIds. > Maybe this behaviour could be reproduced when setting both groupId and > artifactId to * as below : > > > > * > * > **/* > > > > > By the way, I found this, by looking for a way to disable overlay. The > workaround I thought was configuring your plugin to exclude every files when > overlaying. > I think it would be nice to have a configuration parameter for that. > Many thanks, > Dool -- 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] (MWAR-267) Maven WAR plugin does not copy dependencies of type "bundle" into WEB-INF/lib
[
https://jira.codehaus.org/browse/MWAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289244#comment-289244
]
Joerg Schaible commented on MWAR-267:
-
Actually this complete list of types is nonsense! Every Maven plugin has an
extension flag that enables custom artifact types to be respected (defined in a
META-INF/plexus/components.xml). The WAR plugin should simply respect any
artifact on the classpath required for runtime. I cannot see any reason for the
WAR plugin to behave different.
> Maven WAR plugin does not copy dependencies of type "bundle" into WEB-INF/lib
> -
>
> Key: MWAR-267
> URL: https://jira.codehaus.org/browse/MWAR-267
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Any
>Reporter: Thomas Vandahl
>
> A WAR project has transitive dependencies of type "bundle" (mina-core, ...).
> These dependencies do not end up in the WAR file structure under WEB-INF/lib
> as they are supposed to.
> My guess would be the method ArtifactsPackagingTask.performPackaging(), where
> only known types of dependencies are handled, AFAICS. Could the type "bundle"
> be added there? Like:
> {code}
> else if ( "jar".equals( type ) || "ejb".equals( type ) ||
> "ejb-client".equals( type )
> || "test-jar".equals( type ) || "bundle".equals( type ))
> {
> copyFile( id, context, artifact.getFile(), LIB_PATH + targetFileName );
> }
> {code}
--
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] (MEJB-56) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEJB-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289242#comment-289242 ] Anders Hammar commented on MEJB-56: --- It might also be worth analyzing the dependencies of the plugin. dependency:analyze shows there are some declarations missing. > Add Maven version used to Created-By entry in manifest > -- > > Key: MEJB-56 > URL: https://jira.codehaus.org/browse/MEJB-56 > Project: Maven 2.x EJB Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: n/a >Reporter: Anders Hammar > Attachments: MEJB-56.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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] (MEJB-56) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEJB-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MEJB-56: -- Attachment: MEJB-56.patch Attached patch with implemented support. maven-archiver needs to be moved to v2.5 once released. I also needed to upgrade version of some dependencies. I renamed one IT to be more manifest verification generic. > Add Maven version used to Created-By entry in manifest > -- > > Key: MEJB-56 > URL: https://jira.codehaus.org/browse/MEJB-56 > Project: Maven 2.x EJB Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: n/a >Reporter: Anders Hammar > Attachments: MEJB-56.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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
