[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354051#comment-354051 ] Tibor Digana commented on SUREFIRE-855: --- @Robert This would have to be a new parameter in plugin due to backwards compatibility in 2.x. Or other option is to enable a changed behavior of surefire in 3.0 if and only if the build phase = package. What you think ? Allow failsafe to use actual jar file instead of target/classes --- Key: SUREFIRE-855 URL: https://jira.codehaus.org/browse/SUREFIRE-855 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 2.12 Reporter: Benson Margulies Priority: Critical I've got some code that calls Class.getPackage() to see the manifest. I want to test it. A seemingly logical scheme here would be to have failsafe put the actual packaged jar into the classpath instead of the unpacked directory -- or some way to get the manifest copied across. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5699) error running maven project: classpath too long
[ https://jira.codehaus.org/browse/MNG-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354053#comment-354053 ] Michael Osipov commented on MNG-5699: - Are you able to provide a test project to reproduce this issue? error running maven project: classpath too long --- Key: MNG-5699 URL: https://jira.codehaus.org/browse/MNG-5699 Project: Maven Issue Type: Bug Components: Dependencies Affects Versions: 3.2.3 Environment: Windows 8 / Java 8 64 bits Reporter: rui Domingues Hi everyone, I have this maven project. At some point it started throwing this error. Cannot run program C:\Program Files\Java\jdk1.8 .0\jre\bin\java.exe: CreateProcess error=206, The filename or extension is too long I understand this is because of windows command line limit. But I'm struggling because I'm not being able to run my app. How can I solve this? Thanks in advance. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5698) Declare proxies and mirrors in profiles
[ https://jira.codehaus.org/browse/MNG-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5698: Summary: Declare proxies and mirrors in profiles (was: Proxies and Mirrors In Profiles) Declare proxies and mirrors in profiles --- Key: MNG-5698 URL: https://jira.codehaus.org/browse/MNG-5698 Project: Maven Issue Type: Improvement Components: Settings Environment: All Reporter: Edwin Wiles There appear to be 140 issues regarding proxy configuration. None of them appear to have been adequately dealt with. There should be a solution, internal to Maven, preferably in the settings.xml file, that allows the user to either automatically, or at worst with a -P profile argument, to switch between proxies and mirrors. It seems the easiest way to achieve this is to allow proxies and mirrors into profiles, the same as properties and repositories are now. USE CASE: I am presently dealing with an environment where company A has a mirror, proxy, and VPN access; company B has a mirror, proxy, and VPN access; and the user may be working from either company's office, either company's VPN, or from home without using either company's resources. Just making proxies and mirrors acceptable in profiles would go a VERY long way to solving this problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-423) Add support of .pac file for proxy configuration
[
https://jira.codehaus.org/browse/WAGON-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354054#comment-354054
]
Michael Osipov commented on WAGON-423:
--
Another nit, as far as Google can tell me, the {{UrlConnection}} is able to
retreive the system default proxy and obviously even the PAC file. Could you
analyse and verify this?
Add support of .pac file for proxy configuration
Key: WAGON-423
URL: https://jira.codehaus.org/browse/WAGON-423
Project: Maven Wagon
Issue Type: New Feature
Components: wagon-http, wagon-http-lightweight
Reporter: Emmanuel Venisse
Priority: Minor
Authorize Proxy Auto-Config File (.pac file) for proxy configuration in user
model.
http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
=Use rhino for read the pac file.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MECLIPSE-756) Fix RAT Report
Karl-Heinz Marbaise created MECLIPSE-756: Summary: Fix RAT Report Key: MECLIPSE-756 URL: https://jira.codehaus.org/browse/MECLIPSE-756 Project: Maven Eclipse Plugin Issue Type: Improvement Affects Versions: 2.10 Reporter: Karl-Heinz Marbaise Priority: Minor Clean up RAT report warnings / issues -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MECLIPSE-756) Fix RAT Report
[ https://jira.codehaus.org/browse/MECLIPSE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MECLIPSE-756: - Fix Version/s: 2.10 Fix RAT Report -- Key: MECLIPSE-756 URL: https://jira.codehaus.org/browse/MECLIPSE-756 Project: Maven Eclipse Plugin Issue Type: Improvement Affects Versions: 2.10 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: 2.10 Clean up RAT report warnings / issues -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-639) sub-project tries to fetch a site_en.xml even though no locales are configured
[ https://jira.codehaus.org/browse/MSITE-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354083#comment-354083 ] Clinton Foster commented on MSITE-639: -- I know this is an old bug, but I'm also seeing this problem in the 3.4 maven-site-plugin. Trying to find a reasonable workaround... sub-project tries to fetch a site_en.xml even though no locales are configured -- Key: MSITE-639 URL: https://jira.codehaus.org/browse/MSITE-639 Project: Maven Site Plugin Issue Type: Bug Affects Versions: 3.0 Environment: Windows 7 64bit, Sun JDK 1.6.0_27 Reporter: Martin Goldhahn Attachments: parent-project.zip, sub-project.zip I have a parent project that has a site descriptor and a pom project that has the parent project as parent. Neither of them defines the locales parameter of the site plugin. When I try to build the sub-project, I get an error that Maven cannot find the site_en.xml descriptor of the parent project. Why doesn't it just use the site.xml? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5682) Parent POMs not resolved in multi-module project
[
https://jira.codehaus.org/browse/MNG-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354097#comment-354097
]
John Wu commented on MNG-5682:
--
Got similar issue here.
My workaround is to build and install the parent pom first, then build the rest
modules.
Ideally, if the parent pom is in the reactor build plan, the reactor should 1)
build the parent pom prior to build its child modules, 2) pick up the parent
pom from within the reactor and use it for the child modules.
Parent POMs not resolved in multi-module project
Key: MNG-5682
URL: https://jira.codehaus.org/browse/MNG-5682
Project: Maven
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 3.0.4, 3.1.1, 3.2.3
Environment: Apache Maven 3.2.3
(33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
Java version: 1.7.0_67, vendor: Oracle Corporation
Default locale: en_US, platform encoding: Cp1250
OS name: windows 7, version: 6.1, arch: x86, family: windows
Reporter: Kek
Priority: Minor
Attachments: test-project.zip
I have multi-module project - I attach the similar simple project structure
to this issue, to simulate the problem = !test-project.zip!.
The structure is:
{noformat}
A- aggregating project, parent for parent
|_parent - parent for B and C
|_B
|_C
{noformat}
In reality we have more parents under A for diferent types of A-submodules,
but now it does not matter.
When we run build under maven 2.2.1 - everything is OK, the reactor sorts
the projects like A, PARENT, B,C and build success.
When we run the same build under maven 3.x (3.0.4, 3.1.1, 3.2.3 was tested),
the build fails with following errors:
amvn clean
[INFO] Scanning for projects...
[ERROR] The build could not read 2 projects - [Help 1]
[ERROR]
[ERROR] The project a:b:[unknown-version] (\a\b\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
a:parent:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local
POM @ line 6, column 10 - [Help 2]
[ERROR]
[ERROR] The project a:c:[unknown-version] (\a\c\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
a:parent:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local
POM @ line 6, column 10 - [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
There is no explicit relativePath set in project POMs.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-186) Improve error handling based on Mark invalid
Karl-Heinz Marbaise created MRESOURCES-186:
--
Summary: Improve error handling based on Mark invalid
Key: MRESOURCES-186
URL: https://jira.codehaus.org/browse/MRESOURCES-186
Project: Maven Resources Plugin
Issue Type: Improvement
Affects Versions: 2.7
Reporter: Karl-Heinz Marbaise
Priority: Minor
Sometimes is can happen that filtering is done on files which shouldn't be
filtered...which results in the following:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:2.7:resources
(default-resources) on project OrionCommunity: Mark invalid - [Hel
p 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:2.7:resources
(default-resources)
on project OrionCommunity: Mark invalid
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:320)
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.MojoExecutionException: Mark invalid
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:306)
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.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:300)
... 21 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:485)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
at java.io.Reader.read(Reader.java:123)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
{code}
Currently this only crashes the build. But it might be better to create an
appropriate error message for the user.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-187) New parameter in the plugin to be able to use filename filtering.
Karl-Heinz Marbaise created MRESOURCES-187: -- Summary: New parameter in the plugin to be able to use filename filtering. Key: MRESOURCES-187 URL: https://jira.codehaus.org/browse/MRESOURCES-187 Project: Maven Resources Plugin Issue Type: Improvement Affects Versions: 2.7 Reporter: Karl-Heinz Marbaise Priority: Minor I think there is a need of a new parameter in the plugin to be able to use filename filtering. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-186) Improve error handling based on Mark invalid
[
https://jira.codehaus.org/browse/MRESOURCES-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MRESOURCES-186:
---
Fix Version/s: 2.8
Improve error handling based on Mark invalid
Key: MRESOURCES-186
URL: https://jira.codehaus.org/browse/MRESOURCES-186
Project: Maven Resources Plugin
Issue Type: Improvement
Affects Versions: 2.7
Reporter: Karl-Heinz Marbaise
Priority: Minor
Fix For: 2.8
Sometimes is can happen that filtering is done on files which shouldn't be
filtered...which results in the following:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:2.7:resources
(default-resources) on project OrionCommunity: Mark invalid - [Hel
p 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-resources-plugin:2.7:resources
(default-resources)
on project OrionCommunity: Mark invalid
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:320)
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.MojoExecutionException: Mark invalid
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:306)
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.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:300)
... 21 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:485)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
at java.io.Reader.read(Reader.java:123)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
{code}
Currently this only crashes the build. But it might be better to create an
appropriate error message for the user.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-187) New parameter in the plugin to be able to use filename filtering.
[ https://jira.codehaus.org/browse/MRESOURCES-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MRESOURCES-187: --- Fix Version/s: 2.8 New parameter in the plugin to be able to use filename filtering. - Key: MRESOURCES-187 URL: https://jira.codehaus.org/browse/MRESOURCES-187 Project: Maven Resources Plugin Issue Type: Improvement Affects Versions: 2.7 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: 2.8 I think there is a need of a new parameter in the plugin to be able to use filename filtering. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-177) Use version 1.2 of maven-filtering to use improvements
[ https://jira.codehaus.org/browse/MRESOURCES-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354111#comment-354111 ] Karl-Heinz Marbaise commented on MRESOURCES-177: Jerome can please move you comment with your wish to MRESOURCES-187 and remove your comment from this issue. So MRESOURCES-187 will be an improvement for the new release but the current release 2.7 is done. Use version 1.2 of maven-filtering to use improvements -- Key: MRESOURCES-177 URL: https://jira.codehaus.org/browse/MRESOURCES-177 Project: Maven Resources Plugin Issue Type: Improvement Components: filtering Affects Versions: 2.7 Reporter: Jerome RAULINE Assignee: Karl-Heinz Marbaise Fix For: 2.7 Using the version 1.2 will allow to use it's improvements: https://jira.codehaus.org/browse/MSHARED/fixforversion/18729, including my favorite : MSHARED-220 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-715) Upgrade to plexus-archiver 2.6.4 and plexus-io 2.1.4
Kristian Rosenvold created MASSEMBLY-715: Summary: Upgrade to plexus-archiver 2.6.4 and plexus-io 2.1.4 Key: MASSEMBLY-715 URL: https://jira.codehaus.org/browse/MASSEMBLY-715 Project: Maven Assembly Plugin Issue Type: Improvement Reporter: Kristian Rosenvold -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354113#comment-354113
]
Herve Boutemy commented on MSITE-604:
-
@wesson
MSITE-683 is fixed in m-site-p 3.3, so I don't see how the problem is worse
with MSITE-683
and if yçou look at my previous question: I can't reproduce your problem
no problem, no fix
Properties from settings.xml are not recognized in site distribution
management
Key: MSITE-604
URL: https://jira.codehaus.org/browse/MSITE-604
Project: Maven Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Environment: Apache Maven 2.2.1 and 3.0.3
Reporter: Marcin Kuthan
Fix For: backlog
Attachments: MSITE-604-it.patch, MSITE-604-maven3-2.patch,
MSITE-604-maven3.patch, MSITE-604.tgz
My distribution management section looks like:
{code}
distributionManagement
site
id${acme-corporate-pom.siteRepositoryId}/id
url${acme-corporate-pom.siteRepositoryUrl}/url
/site
/distributionManagement
{code}
Where the default property values are defined in the pom:
{code}
properties
acme-corporate-pom.siteRepositoryIdacme-site/acme-corporate-pom.siteRepositoryId
acme-corporate-pom.siteRepositoryUrlscp://sites.intranet.acme.com/var/www/acme-corporate-pom.siteRepositoryUrl
/properties
{code}
I'm able redefine properties from command line, the provided repository is
used instead default one:
{code}
mvn site:site site:deploy
-Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
-Dacme-corporate-pom.siteRepositoryId=somehost
{code}
But when I redefine properties in the profile in {{settings.xml}}, they are
ignored. The profile is activated in {{activeProfiles}} element.
It looks, than only m-site-p ignores properties defined in the
{{settings.xml}} file. m-deploy-p recognizes properties as I expected
(distribution management section for articats deployment is configured in
similar way to site deployment).
--
Marcin Kuthan
Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-130) Using within a delimiter does not work
[
https://jira.codehaus.org/browse/MRESOURCES-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise reassigned MRESOURCES-130:
--
Assignee: Karl-Heinz Marbaise
Using within a delimiter does not work
Key: MRESOURCES-130
URL: https://jira.codehaus.org/browse/MRESOURCES-130
Project: Maven Resources Plugin
Issue Type: Bug
Components: delimiters
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_20
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Christian
Assignee: Karl-Heinz Marbaise
Hi guys,
I am trying to use the pattern %=*% as a delimiter and it is not working.
This is the snippet from my pom.xml:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.4.3/version
configuration
delimiters
delimiterlt;%= * %/delimiter
/delimiters
encodingUTF-8/encoding
/configuration
/plugin
{code}
The resource plugin seems to handle that well like its output let me guess:
{noformat}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources' --
[DEBUG] (f) buildFilters = [C:\.properties]
[DEBUG] (s) delimiters = [%= * %, lll]
[DEBUG] (f) encoding = UTF-8
[DEBUG] (f) escapeWindowsPaths = true
[DEBUG] (s) includeEmptyDirs = false
[DEBUG] (s) outputDirectory = C:\
[DEBUG] (s) overwrite = false
...
[DEBUG] (f) useBuildFilters = true
[DEBUG] (s) useDefaultDelimiters = false
[DEBUG] -- end configuration --
{noformat}
Looking into the resulting files shows me that NOTHING was filtered...
I also tried specifying the delimiter like this:
{code}
delimiter%=*%/delimiter
delimiterlt;%=*%/delimiter
delimiter#60;%=*%/delimiter
delimiter![CDATA[%=*%]]/delimiter
{code}
Nothing worked.
Please fix this or give me any hint what I am doing wrong. I didnt get a
reply on the mailing list
(http://maven.40175.n5.nabble.com/Using-lt-gt-as-delimiter-td3265330.html).
Thx a lot
Cheers
Christian
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-130) Using within a delimiter does not work
[
https://jira.codehaus.org/browse/MRESOURCES-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MRESOURCES-130.
--
Resolution: Fixed
I have created a sample project to verify this.
https://github.com/khmarbaise/mresources/tree/master/mresources-130
With maven-resources-plugin version 2.7 it works in 2.6 it does not.
So i close the issue with fixed. If you have any objections don't hesitate to
reopen the issue.
Using within a delimiter does not work
Key: MRESOURCES-130
URL: https://jira.codehaus.org/browse/MRESOURCES-130
Project: Maven Resources Plugin
Issue Type: Bug
Components: delimiters
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_20
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Christian
Assignee: Karl-Heinz Marbaise
Hi guys,
I am trying to use the pattern %=*% as a delimiter and it is not working.
This is the snippet from my pom.xml:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.4.3/version
configuration
delimiters
delimiterlt;%= * %/delimiter
/delimiters
encodingUTF-8/encoding
/configuration
/plugin
{code}
The resource plugin seems to handle that well like its output let me guess:
{noformat}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-resources-plugin:2.4.3:resources' --
[DEBUG] (f) buildFilters = [C:\.properties]
[DEBUG] (s) delimiters = [%= * %, lll]
[DEBUG] (f) encoding = UTF-8
[DEBUG] (f) escapeWindowsPaths = true
[DEBUG] (s) includeEmptyDirs = false
[DEBUG] (s) outputDirectory = C:\
[DEBUG] (s) overwrite = false
...
[DEBUG] (f) useBuildFilters = true
[DEBUG] (s) useDefaultDelimiters = false
[DEBUG] -- end configuration --
{noformat}
Looking into the resulting files shows me that NOTHING was filtered...
I also tried specifying the delimiter like this:
{code}
delimiter%=*%/delimiter
delimiterlt;%=*%/delimiter
delimiter#60;%=*%/delimiter
delimiter![CDATA[%=*%]]/delimiter
{code}
Nothing worked.
Please fix this or give me any hint what I am doing wrong. I didnt get a
reply on the mailing list
(http://maven.40175.n5.nabble.com/Using-lt-gt-as-delimiter-td3265330.html).
Thx a lot
Cheers
Christian
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-176) CNFE for MavenFilterException
[
https://jira.codehaus.org/browse/MRESOURCES-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MRESOURCES-176.
--
Resolution: Cannot Reproduce
Assignee: Karl-Heinz Marbaise
Based on the comments there is no issue with 2.5 and 2.6 so i close the issue
cause in the meantime we have 2.7 out. If you have further information like an
example project which reproduces the behaviour don't hesitate to reopen the
issue.
CNFE for MavenFilterException
--
Key: MRESOURCES-176
URL: https://jira.codehaus.org/browse/MRESOURCES-176
Project: Maven Resources Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.4.1, 2.6
Environment: Maven 3.0.3, Maven 3.1.1
Reporter: Monish Sen
Assignee: Karl-Heinz Marbaise
While executing goal install with default profile maven resource plugin
version(2.4.1) throws below exception
{code}
[INFO]
[INFO] Building ---Services 1.0-A-SNAPSHOTS
[INFO]
[INFO]
[INFO] --- maven-resources-plugin:2.4.1:resources (default-resources) @
---ServicesWeb ---
Nov 29, 2013 3:06:44 PM org.sonatype.guice.bean.reflect.LoadedClass
WARNING: Error injecting: org.apache.maven.plugin.resources.ResourcesMojo
java.lang.NoClassDefFoundError:
org/apache/maven/shared/filtering/MavenFilteringException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2437)
at java.lang.Class.getDeclaredConstructors(Class.java:1863)
at
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:243)
at
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:96)
at
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:628)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:835)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:769)
at
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:254)
at
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:205)
at
com.google.inject.internal.InjectorImpl.getInternalFactory(InjectorImpl.java:843)
at
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:957)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:990)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:951)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1003)
at
org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:47)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:968)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1014)
at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:964)
at com.google.inject.Scopes$1$1.get(Scopes.java:59)
at
org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:79)
at
org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:53)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:243)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:235)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:455)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
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
[jira] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://jira.codehaus.org/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354118#comment-354118
]
Karl-Heinz Marbaise commented on MRESOURCES-171:
It's also possible to use a separate execution of the maven-resources-plugin
with the copy-resources goal like this with different encoding:
{code:xml}
executions
execution
idcopy-resources/id
phasegenerate-resources/phase
goals
goalcopy-resources/goal
/goals
configuration
encodingWhatEver/encoding
outputDirectory${basedir}/target/extra-resources/outputDirectory
resources
resource
directorysrc/non-packaged-resources/directory
filteringtrue/filtering
/resource
/resources
/configuration
/execution
/executions
{code}
ISO8859-1 properties files get changed into UTF-8 when filtered
---
Key: MRESOURCES-171
URL: https://jira.codehaus.org/browse/MRESOURCES-171
Project: Maven Resources Plugin
Issue Type: Bug
Components: filtering
Reporter: Alex Collins
Priority: Minor
Fix For: backlog
Attachments: filtering-bug.zip
Create:
src/main/resources/test.properties
And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
formatting.
When adding this line:
resourcedirectorysrc/main/resources/directoryfilteringtrue/filtering/resource
Expected:
ISO8859-1 encoded file in jar.
Actual:
UTF-8 encoded file in jar.
---
If there are any property files (which can only be ISO8859-1) they appear to
be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[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 ] Ben Tilford updated MASSEMBLY-588: -- Attachment: assembly.txt Attaching output from Linux Maven 3 JDK 6 Build fails because of 'ls -1nlaR /' Key: MASSEMBLY-588 URL: https://jira.codehaus.org/browse/MASSEMBLY-588 Project: Maven Assembly Plugin Issue Type: Bug Environment: Ubuntu 11.10 (oneiric) Reporter: Thomas Pasch Assignee: Kristian Rosenvold Fix For: 2.3 Attachments: assembly.txt, 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 21 | 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 numeric file attributes using: '/bin/sh -c ls -1nlaR /' at
[jira] (MASSEMBLY-588) Build fails because of 'ls -1nlaR /'
[ https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354119#comment-354119 ] Ben Tilford edited comment on MASSEMBLY-588 at 10/9/14 12:54 PM: - Attaching output from Linux Maven 3 JDK 6 Yesterday several people on Mac, Maven 3, JDK 7 were failing but today they are working. If it helps this problem pops up every couple weeks for the mac users then goes away. was (Author: btilford): Attaching output from Linux Maven 3 JDK 6 Build fails because of 'ls -1nlaR /' Key: MASSEMBLY-588 URL: https://jira.codehaus.org/browse/MASSEMBLY-588 Project: Maven Assembly Plugin Issue Type: Bug Environment: Ubuntu 11.10 (oneiric) Reporter: Thomas Pasch Assignee: Kristian Rosenvold Fix For: 2.3 Attachments: assembly.txt, 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 21 | 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
[jira] (SUREFIRE-855) Allow failsafe to use actual jar file instead of target/classes
[ https://jira.codehaus.org/browse/SUREFIRE-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354120#comment-354120 ] Robert Scholte commented on SUREFIRE-855: - It's not worth adding a parameter just for 2.2.1. And you might call it an improvement, but IMHO the expected behavior is using the jar, so I would consider it a bug. Instead of adding a parameter we could do 2 things: - change the maven prerequisite to 3.0 for the maven-failsafe-plugin so it can use the required improvements. Unlike surefire, which is part of most lifecycles, for the failsafe plugin I think it is valid to do so if this changes the behavior as expected without that many changes. - use reflection to access the Maven 3 methods. We do this more often if we want to support older versions but would like to use new functionality if available. Allow failsafe to use actual jar file instead of target/classes --- Key: SUREFIRE-855 URL: https://jira.codehaus.org/browse/SUREFIRE-855 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 2.12 Reporter: Benson Margulies Priority: Critical I've got some code that calls Class.getPackage() to see the manifest. I want to test it. A seemingly logical scheme here would be to have failsafe put the actual packaged jar into the classpath instead of the unpacked directory -- or some way to get the manifest copied across. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-187) New parameter in the plugin to be able to use filename filtering.
[ https://jira.codehaus.org/browse/MRESOURCES-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354121#comment-354121 ] Jerome RAULINE commented on MRESOURCES-187: --- Hi, I think there is a need of a new parameter in the plugin to be able to use filename filtering. The new Maven maven-filtering need a boolean to allow filename filtering : http://svn.apache.org/viewvc/maven/shared/trunk/maven-filtering/src/main/java/org/apache/maven/shared/filtering/MavenResourcesExecution.java?r1=1568368r2=1568367pathrev=1568368 New parameter in the plugin to be able to use filename filtering. - Key: MRESOURCES-187 URL: https://jira.codehaus.org/browse/MRESOURCES-187 Project: Maven Resources Plugin Issue Type: Improvement Affects Versions: 2.7 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: 2.8 I think there is a need of a new parameter in the plugin to be able to use filename filtering. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-177) Use version 1.2 of maven-filtering to use improvements
[ https://jira.codehaus.org/browse/MRESOURCES-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerome RAULINE updated MRESOURCES-177: -- Comment: was deleted (was: Hi, I think there is a need of a new parameter in the plugin to be able to use filename filtering. The new Maven maven-filtering need a boolean to allow filename filtering : http://svn.apache.org/viewvc/maven/shared/trunk/maven-filtering/src/main/java/org/apache/maven/shared/filtering/MavenResourcesExecution.java?r1=1568368r2=1568367pathrev=1568368) Use version 1.2 of maven-filtering to use improvements -- Key: MRESOURCES-177 URL: https://jira.codehaus.org/browse/MRESOURCES-177 Project: Maven Resources Plugin Issue Type: Improvement Components: filtering Affects Versions: 2.7 Reporter: Jerome RAULINE Assignee: Karl-Heinz Marbaise Fix For: 2.7 Using the version 1.2 will allow to use it's improvements: https://jira.codehaus.org/browse/MSHARED/fixforversion/18729, including my favorite : MSHARED-220 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-709) When assembling a zip on windows duplicate files are added to the assembly
[
https://jira.codehaus.org/browse/MASSEMBLY-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354122#comment-354122
]
Karl-Heinz Marbaise commented on MASSEMBLY-709:
---
I have tested the current trunk with the example project and unfortunately it
has not changed.
When assembling a zip on windows duplicate files are added to the assembly
--
Key: MASSEMBLY-709
URL: https://jira.codehaus.org/browse/MASSEMBLY-709
Project: Maven Assembly Plugin
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.4, 2.4.1
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 05:51:28-0800)
Maven home: C:\bin\apache-maven-3.0.5
Java version: 1.7.0_60, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_60\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows server 2008 r2, version: 6.1, arch: amd64, family:
windows
Reporter: Jason Lemay
Fix For: 2.5
Attachments: sample.zip
When assembling a zip where duplicate files are copied to the output
directory the default behavior is for the first file to copy and the
remaining ones to be skipped. When building a project on windows this is not
the behavior. On Windows all the duplicate files are added to the final zip
assembly.
This was tested on OSX, CentOS, and Windows Server 2009 R2.
Using OSX with these settings:
{code}
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
05:51:28-0800)
Maven home: /usr/local/Cellar/maven30/3.0.5/libexec
Java version: 1.7.0_60, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.9.4, arch: x86_64, family: mac
{code}
Running the mvn build as such:
{code}
mvn -X clean install
{code}
You end up with this logged to the console:
{code}
[INFO] Building zip: /Users/jasonl/Desktop/sample/target/sample.zip
[DEBUG] adding directory sample/
[DEBUG] adding directory sample/conf/
[DEBUG] adding entry sample/conf/ConfFile.txt
[DEBUG] adding entry sample/file.txt
[DEBUG] sample/conf/ConfFile.txt already added, skipping
{code}
When the final zip is examined there are no duplicate files. The plugin
worked as intended. The same results were obtained in the CentOS test.
The problem arises when you build on windows.
Building with these settings:
{code}
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
05:51:28-0800)
Maven home: C:\bin\apache-maven-3.0.5
Java version: 1.7.0_60, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_60\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows server 2008 r2, version: 6.1, arch: amd64, family:
windows
{code}
And running the same mvn command:
{code}
mvn -X clean install
{code}
The following is output to the console:
{code}
[INFO] Building zip: C:\Users\Administrator\Desktop\sample\target\sample.zip
[DEBUG] adding directory sample/
[DEBUG] adding directory sample/conf/
[DEBUG] adding entry sample/conf/ConfFile.txt
[DEBUG] adding entry sample/file.txt
[DEBUG] adding entry sample/conf/ConfFile.txt
{code}
As you can see the assembly did not skip the second ConfFile.txt addition.
When the final zip assembly is examined there is infact 2 ConfFile.txt files
under the conf directory.
Attached is the sample I used.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-177) Use version 1.2 of maven-filtering to use improvements
[ https://jira.codehaus.org/browse/MRESOURCES-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MRESOURCES-177: --- Comment: was deleted (was: Jerome can please move you comment with your wish to MRESOURCES-187 and remove your comment from this issue. So MRESOURCES-187 will be an improvement for the new release but the current release 2.7 is done.) Use version 1.2 of maven-filtering to use improvements -- Key: MRESOURCES-177 URL: https://jira.codehaus.org/browse/MRESOURCES-177 Project: Maven Resources Plugin Issue Type: Improvement Components: filtering Affects Versions: 2.7 Reporter: Jerome RAULINE Assignee: Karl-Heinz Marbaise Fix For: 2.7 Using the version 1.2 will allow to use it's improvements: https://jira.codehaus.org/browse/MSHARED/fixforversion/18729, including my favorite : MSHARED-220 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-177) Use version 1.2 of maven-filtering to use improvements
[ https://jira.codehaus.org/browse/MRESOURCES-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MRESOURCES-177. -- Resolution: Fixed Closed cause it's fixed with 2.7 Use version 1.2 of maven-filtering to use improvements -- Key: MRESOURCES-177 URL: https://jira.codehaus.org/browse/MRESOURCES-177 Project: Maven Resources Plugin Issue Type: Improvement Components: filtering Affects Versions: 2.7 Reporter: Jerome RAULINE Assignee: Karl-Heinz Marbaise Fix For: 2.7 Using the version 1.2 will allow to use it's improvements: https://jira.codehaus.org/browse/MSHARED/fixforversion/18729, including my favorite : MSHARED-220 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-186) Improve error handling based on Mark invalid
[
https://jira.codehaus.org/browse/MRESOURCES-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MRESOURCES-186:
---
Description:
Sometimes it can happen that filtering is done on files which shouldn't be
filtered...which results in the following:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:2.7:resources
(default-resources) on project OrionCommunity: Mark invalid - [Hel
p 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:2.7:resources
(default-resources)
on project OrionCommunity: Mark invalid
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:320)
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.MojoExecutionException: Mark invalid
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:306)
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.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:300)
... 21 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:485)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
at java.io.Reader.read(Reader.java:123)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
{code}
Currently this only crashes the build. But it might be better to create an
appropriate error message for the user.
was:
Sometimes is can happen that filtering is done on files which shouldn't be
filtered...which results in the following:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:2.7:resources
(default-resources) on project OrionCommunity: Mark invalid - [Hel
p 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:2.7:resources
(default-resources)
on project OrionCommunity: Mark invalid
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
[jira] (MJAVADOC-365) [Patch] sourceFileExcludes does not work due to inclusion of packages
[ https://jira.codehaus.org/browse/MJAVADOC-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MJAVADOC-365: --- Assignee: Robert Scholte [Patch] sourceFileExcludes does not work due to inclusion of packages - Key: MJAVADOC-365 URL: https://jira.codehaus.org/browse/MJAVADOC-365 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9 Reporter: Michael Bayne Assignee: Robert Scholte Attachments: MJAVADOC-365-REC-2014-10-09-a.patch, MJAVADOC-365-REC-2014-10-09.patch, patch If you specify sourceFileExcludes for Javadoc generation, they are ignored, because the plugin always supplies a list of packages to Javadoc instead of a list of source files. This is easily remedied with the attached patch. It causes the plugin to switch to pass a list of source files to Javadoc mode if any sourceFileExcludes are supplied. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-588) Build fails because of 'ls -1nlaR /'
[ https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354124#comment-354124 ] Kristian Rosenvold commented on MASSEMBLY-588: -- @Ben; you claim to be running assembly 2.4.1 but your log file shows you are running version 2.2.2. I suggest you try to find the cause of this first. Build fails because of 'ls -1nlaR /' Key: MASSEMBLY-588 URL: https://jira.codehaus.org/browse/MASSEMBLY-588 Project: Maven Assembly Plugin Issue Type: Bug Environment: Ubuntu 11.10 (oneiric) Reporter: Thomas Pasch Assignee: Kristian Rosenvold Fix For: 2.3 Attachments: assembly.txt, 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 21 | 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:
[jira] (MASSEMBLY-638) [PATCH] Support tgz and tbz2 formats in assemblies
[ https://jira.codehaus.org/browse/MASSEMBLY-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-638. Resolution: Fixed Fix Version/s: 2.5 Applied in r1630554, thanks for the patch ! [PATCH] Support tgz and tbz2 formats in assemblies -- Key: MASSEMBLY-638 URL: https://jira.codehaus.org/browse/MASSEMBLY-638 Project: Maven Assembly Plugin Issue Type: Improvement Components: maven-archiver Affects Versions: 2.4 Reporter: Sergei Ivanov Assignee: Kristian Rosenvold Fix For: 2.5 Attachments: tgz.patch Allow two new output formats (tgz and tbz2) to be specified in assembly descriptors. These formats are aliases for tar.gz and tar.bz2 respectively, differing only in file extension. The patch (against the latest SVN trunk) is trivial, and includes updated test cases and updated site documentation. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-479) Add option to generate Posix tar files.
[ https://jira.codehaus.org/browse/MASSEMBLY-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-479. Resolution: Fixed Fix Version/s: 2.5 Assignee: Kristian Rosenvold Posix support is added through the tarLongFileMode setting. (Note; this may have been fixed prior to 2.5 but undocumented. I did not check) Add option to generate Posix tar files. --- Key: MASSEMBLY-479 URL: https://jira.codehaus.org/browse/MASSEMBLY-479 Project: Maven Assembly Plugin Issue Type: Improvement Environment: AIX, systems using Posix tar utility. Reporter: Jamie Goodyear Assignee: Kristian Rosenvold Fix For: 2.5 On some systems gnu tar utility is not present however posix tar does exist. It would be nice if we could specify as a target ptar as a file format to allow users of the assembly plugin to generate this particular kind of tar file. As a note, using posix tar to extract a gnu tar file results in truncated files and other anomalies. The difference in tar format is described here in detail http://www.delorie.com/gnu/docs/tar/tar_114.html As a work around for users that need an archive format, but can not use zip or gnu tar, they can try building their files into a jar file. The jar utility can then be used to extract the contents. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MASSEMBLY-557:
-
Fix Version/s: 2.5
Corrupted zip created by assembly: extracting the zip forgets certain folders
(or throws permission denied errors) possibly because zip index is corrupted
--
Key: MASSEMBLY-557
URL: https://jira.codehaus.org/browse/MASSEMBLY-557
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
Fix For: 2.5
Attachments:
droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
Take a look at the attached zip created by the assembly plugin.
- If you open it, you can see navigate to the submap
/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
map you find the file droolsjbpm-integration-docs.pdf which you can open with
a PDF reader.
- If instead you extract the entire archive to a directory, and navigate to
the submap
/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
find that that map is unreadable (chmod 000) and the pdf file is gone.
The directories html_single and html suffer the same fate, but none of the
other directories do.
I used the default linux Ubuntu 10.10 archive manager (which according to
about screen is called File-roller 2.32.0).
I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
Note that that attached zip is gutted to stay inside the maximum file upload
size.
Possible reproduce recipe:
{code}
git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
cd droolsjbpm-integration
git checkout 5.2.0.M2
mvn clean install -DskipTests -Dfull
cd droolsjbpm-integration/target
ls
{code}
{code}
checkdir error: cannot create
/home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
Permission denied
unable to process
droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
...
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-557) Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted
[
https://jira.codehaus.org/browse/MASSEMBLY-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354128#comment-354128
]
Kristian Rosenvold commented on MASSEMBLY-557:
--
Assembly 2.5 (currently known as 2.4.2-SNAPSHOT) has switched fully to
commons-compress, meaning most of the code base that was used in prior versons
is gone. This should fix this bug. Please do test this version, I will close
this issue at release time (about 6 days from today) unless someone complains.
Corrupted zip created by assembly: extracting the zip forgets certain folders
(or throws permission denied errors) possibly because zip index is corrupted
--
Key: MASSEMBLY-557
URL: https://jira.codehaus.org/browse/MASSEMBLY-557
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
Fix For: 2.5
Attachments:
droolsjbpm-integration-distribution-5.2.0.M2_BROKEN_IN_reference_manual_gutted.zip
Take a look at the attached zip created by the assembly plugin.
- If you open it, you can see navigate to the submap
/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/. In that
map you find the file droolsjbpm-integration-docs.pdf which you can open with
a PDF reader.
- If instead you extract the entire archive to a directory, and navigate to
the submap
/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/pdf/, you 'll
find that that map is unreadable (chmod 000) and the pdf file is gone.
The directories html_single and html suffer the same fate, but none of the
other directories do.
I used the default linux Ubuntu 10.10 archive manager (which according to
about screen is called File-roller 2.32.0).
I used Maven 3.0.3, maven-assembly-plugin 2.2.1.
Note that that attached zip is gutted to stay inside the maximum file upload
size.
Possible reproduce recipe:
{code}
git clone g...@github.com:droolsjbpm/droolsjbpm-integration.git
cd droolsjbpm-integration
git checkout 5.2.0.M2
mvn clean install -DskipTests -Dfull
cd droolsjbpm-integration/target
ls
{code}
{code}
checkdir error: cannot create
/home/gdesmet/tmp/releases/problem_with_the_release_zip/droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images
Permission denied
unable to process
droolsjbpm-integration-distribution-5.2.0.M2/reference_manual/html_single/images/.
...
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-622) Unable to create TAR artifacts
[ https://jira.codehaus.org/browse/MASSEMBLY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-622: - Fix Version/s: 2.5 Unable to create TAR artifacts Key: MASSEMBLY-622 URL: https://jira.codehaus.org/browse/MASSEMBLY-622 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.3 Environment: [aelmadho@aelmadho-laptop Kernel]$ mvn -version Apache Maven 3.0.4 (rNON-CANONICAL_2012-07-25_12-05_mockbuild; 2012-07-25 08:05:49-0400) Maven home: /usr/share/maven Java version: 1.7.0_05-icedtea, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.5.0-2.fc17.x86_64, arch: amd64, family: unix Reporter: Ahmed El-Madhoun Priority: Critical Fix For: 2.5 Attachments: assembly.xml, maven-assembly-error.txt, pom.xml To reproduce the case, you may need to just re-point the POM to the assembly descriptor attached. I am simply able to do the same if I specify a type of jar or zip, but not when using any sort of tar based type. We are using this as a primary basis of our build, which is primarily in C, and I would greatly appreciate any help or feedback on this item. Alot of thanks on the great work already! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-530) Allow configuration of encoding
[ https://jira.codehaus.org/browse/MASSEMBLY-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-530: - Fix Version/s: 2.5 Allow configuration of encoding Key: MASSEMBLY-530 URL: https://jira.codehaus.org/browse/MASSEMBLY-530 Project: Maven Assembly Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Max Schaefer Fix For: 2.5 Zips, that encode the file names with e.g. UTF-8 are not properly unpacked because the system default encoding is assumed. I tracked down that PlexusIoZipFileResourceCollection initialises a ZipFile instance passing in just the file. However, a second parameter of ZipFile allows to control the encoding. I would like to be able to specify that encoding when unpacking a dependencySet. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-647) Archiver drops file/directory mode most significant bits
[
https://jira.codehaus.org/browse/MASSEMBLY-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354129#comment-354129
]
Kristian Rosenvold commented on MASSEMBLY-647:
--
AFAIK there is no way to set these bits with java
Archiver drops file/directory mode most significant bits
Key: MASSEMBLY-647
URL: https://jira.codehaus.org/browse/MASSEMBLY-647
Project: Maven Assembly Plugin
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.4
Reporter: Leif Rilbe
Problem detected when trying to build a zip assembly with directories having
the setgid bit set.
Wanted directory mode: drwxrws---
Archiver config:
archiverConfig
!-- (rwxrws===) = 2770(oct) --
directoryMode1528/directoryMode
defaultDirectoryMode1528/defaultDirectoryMode
/archiverConfig
FileSet config in assembly descriptor:
fileSet
directory${project.build.directory}/directory
includes
include.//include
/includes
outputDirectory//outputDirectory
directoryMode2770/directoryMode
/fileSet
Actual directory mode: drwxrwx---
If I do not specify directoryMode in the assembly descriptor, the modes
from the archiverConfig prevale, thus yielding the wanted directory mode.
However, this behaviour seems brittle and possibly any use of fileMode or
directoryMode in the assembly descriptors seems to break the use of the
archiverConfig modes.
From source code analysis it seems to me that fileset modes are handled by
means of the org.codehaus.plexus.components.io.attributes.FileAttributes
class. This class seems to not handle the most significant file mode bits
(i.e. setuid/setgid/sticky bits). It seems that the assembly plugin sometimes
routes permission through this class and sometimes not, which causes the most
significant bits to be sometimes lost and sometimes not.
Perhaps the best route would be to add handling of the setuid/setgid/sticky
bits to the org.codehaus.plexus.components.io.attributes.FileAttributes class?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-605) Filtering does not work on files which are symlinks
[
https://jira.codehaus.org/browse/MASSEMBLY-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MASSEMBLY-605:
-
Fix Version/s: 2.5
Filtering does not work on files which are symlinks
---
Key: MASSEMBLY-605
URL: https://jira.codehaus.org/browse/MASSEMBLY-605
Project: Maven Assembly Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.2.1, 2.3
Environment: Linux REL 5, JDK6
Reporter: Lucas Persson
Fix For: 2.5
Filtering does not work on files which are symlinks. The files gets copied so
it is not totally broken.
The resource plugin seems to handle this correctly.
Typical assmbly descriptor:
?xml version=1.0?
assembly
idinstall-jrf/id
formats
formatzip/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
baseDirectory${project.artifactId}/baseDirectory
includeSiteDirectoryfalse/includeSiteDirectory
fileSets
fileSet
outputDirectory/outputDirectory
directorysrc/main/resources/directory
filteredtrue/filtered
/fileSet
/fileSets
/assembly
If files under src/main/resources are symlinks they will be copied but not
filtered.
I get this warning/info in the log(running 2.2.1):
[DEBUG] All known ContainerDescriptorHandler components: [file-aggregator,
metaInf-spring, metaInf-services, plexus]
[DEBUG] No dependency sets specified.
[DEBUG] FileSet[] dir perms: -1 file perms: -1
[DEBUG] The archive base directory is 'null'
[INFO] No files selected for line-ending conversion or filtering. Skipping:
/scratch/lupersso/view_storage/lupersso_pcbpel/pcbpel/ums/worklist-tmpl/src/main/resources
[DEBUG] Adding file-set from directory:
'/scratch/lupersso/view_storage/lupersso_pcbpel/pcbpel/ums/worklist-tmpl/src/main/resources'
assembly output directory is: ''
[DEBUG] Adding file-set in:
/scratch/lupersso/view_storage/lupersso_pcbpel/pcbpel/ums/worklist-tmpl/src/main/resources
to archive location:
(The project's pom.xml is in the
/scratch/lupersso/view_storage/lupersso_pcbpel/pcbpel/ums/worklist-tmpl
folder)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-365) [Patch] sourceFileExcludes does not work due to inclusion of packages
[ https://jira.codehaus.org/browse/MJAVADOC-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJAVADOC-365. --- Resolution: Fixed Fix Version/s: 2.11 Fixed in [r1630574|http://svn.apache.org/r1630574] Thanks for the complete patch! [Patch] sourceFileExcludes does not work due to inclusion of packages - Key: MJAVADOC-365 URL: https://jira.codehaus.org/browse/MJAVADOC-365 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9 Reporter: Michael Bayne Assignee: Robert Scholte Fix For: 2.11 Attachments: MJAVADOC-365-REC-2014-10-09-a.patch, MJAVADOC-365-REC-2014-10-09.patch, patch If you specify sourceFileExcludes for Javadoc generation, they are ignored, because the plugin always supplies a list of packages to Javadoc instead of a list of source files. This is easily remedied with the attached patch. It causes the plugin to switch to pass a list of source files to Javadoc mode if any sourceFileExcludes are supplied. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-817) JUnit 4.7 test output is always buffered, lost if forked process exits abnormally
[ https://jira.codehaus.org/browse/SUREFIRE-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354134#comment-354134 ] Tibor Digana commented on SUREFIRE-817: --- @Todd Lipcon Can you tell us if surefire 2.12.3 works fine for you now? Is the latest version 2.17 reports the latest logs at system exit? JUnit 4.7 test output is always buffered, lost if forked process exits abnormally - Key: SUREFIRE-817 URL: https://jira.codehaus.org/browse/SUREFIRE-817 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.11 Reporter: Todd Lipcon The junit47 provider and above support multi-threaded test execution, and thus interpose a buffering layer (ConcurrentReporterManager) in between the test output and the actual stderr/stdout. This is ostensibly to allow the multiple threads' stderr and stdout to be demuxed nicely when the suite completes. But, if the JVM exits abnormally (eg due to a segfault or a System.exit() call), no output is generated. This is problematic since it's very hard to debug the test failure! In my opinion, the buffering layer should only be interposed _when parallel running is enabled_. For the non-parallel case, there's no need to buffer the output. A simple test case is to write a JUnit test which prints a line of output to stderr and then calls System.exit(1). The output doesn't show up anywhere. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-904) Categorization of tests results in running first tests without categorization,then tests run based on category
[
https://jira.codehaus.org/browse/SUREFIRE-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354135#comment-354135
]
Tibor Digana commented on SUREFIRE-904:
---
@Ronal Bashirov
Any objections to closing this issue?
Categorization of tests results in running first tests without
categorization,then tests run based on category
--
Key: SUREFIRE-904
URL: https://jira.codehaus.org/browse/SUREFIRE-904
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.12.2
Environment: maven 3.0.4
junit 4.8.1
maven surefire pluign 2.12.2
Reporter: Ronal Bashirov
Attachments: mavenproject2.zip
I am separate my tests using junit categories.
So I have some test:
@Test
@Category(UnitTest.class)
public void testApp1() {
System.out.println( UnitTest );
assertTrue(true);
}
@Test
@Category(ComponentTest.class)
public void testApp2() {
System.out.println( ComponentTest );
assertTrue(true);
}
@Test
@Category(SystemTest.class)
public void testApp3() {
System.out.println( SystemTest );
assertTrue(true);
}
Then I am trying to run them separately
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.12.2/version
executions
execution
idunit-tests/id
goals
goaltest/goal
/goals
configuration
groupscom.mycompany.mavenproject2.UnitTest/groups
reportsDirectory
${project.build.directory}/surefire-reports/unit/reportsDirectory
/configuration
/execution
execution
idcomp-tests/id
goals
goaltest/goal
/goals
configuration
groupscom.mycompany.mavenproject2.ComponentTest/groups
reportsDirectory
${project.build.directory}/surefire-reports/comp/reportsDirectory
/configuration
/execution
execution
idsys-tests/id
goals
goaltest/goal
/goals
configuration
groupscom.mycompany.mavenproject2.SystemTest/groups
reportsDirectory
${project.build.directory}/surefire-reports/sys/reportsDirectory
/configuration
/execution
/executions
/plugin
As result I am getting
---
T E S T S
---
Running com.mycompany.mavenproject2.AppTest
UnitTest
ComponentTest
SystemTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[surefire:test]
Surefire report directory:
C:\Users\mz\Documents\NetBeansProjects\mavenproject2\target\surefire-reports\unit
---
T E S T S
---
Concurrency config is parallel='none', perCoreThreadCount=true,
threadCount=2, useUnlimitedThreads=false
Running com.mycompany.mavenproject2.AppTest
UnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[surefire:test]
Surefire report directory:
C:\Users\mz\Documents\NetBeansProjects\mavenproject2\target\surefire-reports\comp
---
T E S T S
---
Concurrency config is parallel='none', perCoreThreadCount=true,
threadCount=2, useUnlimitedThreads=false
Running com.mycompany.mavenproject2.AppTest
ComponentTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[surefire:test]
Surefire report directory:
C:\Users\mz\Documents\NetBeansProjects\mavenproject2\target\surefire-reports\sys
---
T E S T S
[jira] (MASSEMBLY-588) Build fails because of 'ls -1nlaR /'
[ https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354136#comment-354136 ] Ben Tilford edited comment on MASSEMBLY-588 at 10/9/14 4:51 PM: Dependency management was off but issue is still there with 2.4.1 Re-uploaded was (Author: btilford): Dependency management was off but issue is still there with 2.4.1 Build fails because of 'ls -1nlaR /' Key: MASSEMBLY-588 URL: https://jira.codehaus.org/browse/MASSEMBLY-588 Project: Maven Assembly Plugin Issue Type: Bug Environment: Ubuntu 11.10 (oneiric) Reporter: Thomas Pasch Assignee: Kristian Rosenvold Fix For: 2.3 Attachments: assembly-2.4.1.txt, assembly.txt, 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 21 | 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
[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 ] Ben Tilford updated MASSEMBLY-588: -- Attachment: assembly-2.4.1.txt Dependency management was off but issue is still there with 2.4.1 Build fails because of 'ls -1nlaR /' Key: MASSEMBLY-588 URL: https://jira.codehaus.org/browse/MASSEMBLY-588 Project: Maven Assembly Plugin Issue Type: Bug Environment: Ubuntu 11.10 (oneiric) Reporter: Thomas Pasch Assignee: Kristian Rosenvold Fix For: 2.3 Attachments: assembly-2.4.1.txt, assembly.txt, 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 21 | 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 numeric file attributes using:
[jira] (MASSEMBLY-458) Directory name resolution ignores $ and beyond
[ https://jira.codehaus.org/browse/MASSEMBLY-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-458. Resolution: Fixed Fix Version/s: 2.5 Assignee: Kristian Rosenvold Tested with 2.5-SNAPSHOT, and this now works. I am closing this issue with a target of 2.5, even though it may have been fixed earlier Directory name resolution ignores $ and beyond Key: MASSEMBLY-458 URL: https://jira.codehaus.org/browse/MASSEMBLY-458 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: Fedora 12, Intel x86 Reporter: Shantanu Kumar Assignee: Kristian Rosenvold Fix For: 2.5 Attachments: jettify.tar.bz2 When assembling sources, the directory name containing $ is read incorrectly. For example, abc$def is read as abc. This is causing path resolution problems. Please try creating assemblies from the attached project (it is Open Source under Apache 2 license). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-365) [Patch] sourceFileExcludes does not work due to inclusion of packages
[ https://jira.codehaus.org/browse/MJAVADOC-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354140#comment-354140 ] Savas Ali Tokmen commented on MJAVADOC-365: --- Thanks, everyone :) Is there a target date for the Javadoc plugin's 2.11 release? [Patch] sourceFileExcludes does not work due to inclusion of packages - Key: MJAVADOC-365 URL: https://jira.codehaus.org/browse/MJAVADOC-365 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9 Reporter: Michael Bayne Assignee: Robert Scholte Fix For: 2.11 Attachments: MJAVADOC-365-REC-2014-10-09-a.patch, MJAVADOC-365-REC-2014-10-09.patch, patch If you specify sourceFileExcludes for Javadoc generation, they are ignored, because the plugin always supplies a list of packages to Javadoc instead of a list of source files. This is easily remedied with the attached patch. It causes the plugin to switch to pass a list of source files to Javadoc mode if any sourceFileExcludes are supplied. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-563) JAR entry not found when including jar dependencies with # in classname
[
https://jira.codehaus.org/browse/MASSEMBLY-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-563.
Resolution: Fixed
Fix Version/s: 2.5
Assignee: Kristian Rosenvold
JAR entry not found when including jar dependencies with # in classname
-
Key: MASSEMBLY-563
URL: https://jira.codehaus.org/browse/MASSEMBLY-563
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.2.1
Environment: Linux
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
2.6.32-32-generic #62-Ubuntu SMP Wed Apr 20 21:52:38 UTC 2011 x86_64 GNU/Linux
Reporter: Youri Bonnaffé
Assignee: Kristian Rosenvold
Fix For: 2.5
I'm building an assembly using a dependencySet. Every jar is included.
I get an error message Failed to create assembly: Error creating assembly
archive jars-with-dependencies: Problem creating jar: JAR entry
com/extjs/gxt/ui/client/widget/grid/GridTemplates not found in
/home/ybonnaffemoity/mavenRepository/com/extjs/gxt/2.2.1-custo-1/gxt-2.2.1-custo-1.jar.
It turns out that the incriminated class has also HTML files in the same
folder (GridTemplates#startGroup.html for instance). If I remove theses
files, the assembly will be created. I suspect the # character to be
responsible of this.
Assembly descriptor:
{code:xml}
?xml version=1.0 encoding=UTF-8?
assembly
idjars-with-dependencies/id
formats
formatjar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directory${project.build.outputDirectory}/directory
outputDirectory//outputDirectory
/fileSet
/fileSets
dependencySets
dependencySet
outputDirectory//outputDirectory
unpacktrue/unpack
includes
include*:jar:*/include
/includes
/dependencySet
/dependencySets
/assembly
{code}
{noformat}
jar -tf gxt-2.2.1-custo-1.jar | grep GridTemplates
com/extjs/gxt/ui/client/widget/grid/GridTemplates#body.html
com/extjs/gxt/ui/client/widget/grid/GridTemplates#endGroup.html
com/extjs/gxt/ui/client/widget/grid/GridTemplates#master.html
com/extjs/gxt/ui/client/widget/grid/GridTemplates#startGroup.html
com/extjs/gxt/ui/client/widget/grid/GridTemplates.class
com/extjs/gxt/ui/client/widget/grid/GridTemplates.java
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
