[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=296800#comment-296800
]
Geoffrey De Smet edited comment on MASSEMBLY-557 at 5/14/12 3:57 AM:
-
Reproduced with assembly plugin 2.2.2 too (after upgrading from 2.2.1).
@Christoph Your 2.3.0 problem is definitely different then ours. I recommend
you open a different jira and since you can reproduce it consistently, you
might want to extract a simple project to reproduce it.
was (Author: ge0ffrey):
I've upgraded our assembly plugin to 2.2.2 (from 2.2.1) to check if it
still happens.
@Christoph Your 2.3.0 problem is definitely different then ours. I recommend
you open a different jira and since you can reproduce it consistently, you
might want to extract a simple project to reproduce it.
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 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-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=298607#comment-298607
]
Geoffrey De Smet commented on MASSEMBLY-557:
Reproduced with assembly plugin 2.3, even with explicitly stating
fileMode755/fileMode.
However I did notice something important: It only happens with dependencySet
with unpacktrue/unpack.
This code can have it:
{code}
dependencySet
includes
includeorg.drools.planner:drools-planner-core:*:javadoc/include
/includes
outputDirectoryjavadoc/outputDirectory
unpacktrue/unpack
useStrictFilteringtrue/useStrictFiltering
/dependencySet
dependencySet
includes
includeorg.drools.planner:drools-planner-docs:jdocbook/include
/includes
outputDirectoryreference_manual/outputDirectory
unpacktrue/unpack
unpackOptions
excludes
excludeMETA-INF/**/exclude
/excludes
/unpackOptions
useStrictFilteringtrue/useStrictFiltering
/dependencySet
{code}
This code does not have it:
{code}
!-- Javadocs --
fileSet
directory${project.build.directory}/aggregated-javadocs/apidocs/directory
outputDirectoryjavadocs/outputDirectory
/fileSet
{code}
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 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-87) help:effective-pom uses platform encoding and garbles non-ascii characters, emits invalid XML
[
https://jira.codehaus.org/browse/MPH-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298611#comment-298611
]
Jürgen Hermann commented on MPH-87:
---
Writing the result to a file doesn't really help (then the file's content is
broken, i.e. not well-formed XML). Consider this:
{code}
$ head -n1 pom.xml
?xml version=1.0?
$ grep -m1 name pom.xml | xxd
000: 2020 2020 3c6e 616d 653e 4d75 6c74 692d nameMulti-
010: 4172 6368 6574 7970 6573 2052 6f6f 7420 Archetypes Root
020: 504f 4d20 c3a4 c3b6 c3bc c39f 3c2f 6e61 POM /na
030: 6d65 3e0ame.
$ MAVEN_OPTS=-Dfile.encoding=iso-8859-15 mvn -Doutput=effective.xml
help:effective-pom
...
[INFO] Multi-Archetypes Root POM #65533;#65533;#65533;
...
$ head -n1 effective.xml
?xml version=1.0 encoding=UTF-8?
$ xmllint effective.xml
effective.xml:26: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xE4 0xF6 0xFC 0xDF
nameMulti-Archetypes Root POM #65533;#65533;#65533;#65533;/name
{code}
i.e. we have a pom.xml with default encoding (UTF-8) containing some properly
encoded umlauts (c3a4...). The Maven run (with simulating a system that uses
Latin-9) already doesn't read that correctly and emits replacement characters.
The resulting XML is a mess, stating *explicitely* it's UTF-8, while containing
Latin-9.
In summary: Maven doesn't behave deterministically here, and depends on the
system environment where it shouldn't, leading to hard to find problems that
occur out of the blue for some developers only.
help:effective-pom uses platform encoding and garbles non-ascii characters,
emits invalid XML
-
Key: MPH-87
URL: https://jira.codehaus.org/browse/MPH-87
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Windows, MacOSX, Linux, Maven 3.0.4
Reporter: Mirko Friedenhagen
Attachments: mfriedenhagen-invalidpom-MPH-87-0-g42a5c31.zip
As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files
without a BOM and without a XML encoding declaration should read the XML as
UTF-8.
{{help:effective-pom}} does use the platform encoding for writing the
effective-pom without emitting an appropriate XML encoding declaration in the
resulting XML file.
I have created a small sample project (available at
https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will
reproduce the issue.
While the parent pom
(https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML
encoding declaration,
https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml
has none.
Now running:
{code}
mvn -s settings.xml -gs settings.xml clean validate
{code}
will produce an invalid character for the developer name Jörg in
{{child-invalid}}.
Two workarounds are:
* to include a XML encoding declaration as done in {{child-valid}}.
* to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in
http://stackoverflow.com/a/623036/49132
* to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs
settings.xml clean validate}}.
Nonetheless I consider this a Major bug, as it clearly violates the
recommendations of W3C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-87) help:effective-pom uses platform encoding and garbles non-ascii characters, emits invalid XML
[
https://jira.codehaus.org/browse/MPH-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298611#comment-298611
]
Jürgen Hermann edited comment on MPH-87 at 5/14/12 6:07 AM:
Writing the result to a file doesn't really help (then the file's content is
broken, i.e. not well-formed XML). Consider this:
{code}
$ head -n1 pom.xml
?xml version=1.0?
$ grep -m1 name pom.xml | xxd
000: 2020 2020 3c6e 616d 653e 4d75 6c74 692d nameMulti-
010: 4172 6368 6574 7970 6573 2052 6f6f 7420 Archetypes Root
020: 504f 4d20 c3a4 c3b6 c3bc c39f 3c2f 6e61 POM /na
030: 6d65 3e0ame.
$ MAVEN_OPTS=-Dfile.encoding=iso-8859-15 mvn -Doutput=effective.xml
help:effective-pom
...
[INFO] Multi-Archetypes Root POM #65533;#65533;#65533;
...
$ head -n1 effective.xml
?xml version=1.0 encoding=UTF-8?
$ xmllint effective.xml
effective.xml:26: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xE4 0xF6 0xFC 0xDF
nameMulti-Archetypes Root POM #65533;#65533;#65533;#65533;/name
$ mvn -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: linux, version: 3.0.0-12-generic-pae, arch: i386, family: unix
{code}
i.e. we have a pom.xml with default encoding (UTF-8) containing some properly
encoded umlauts (c3a4...). The Maven run (with simulating a system that uses
Latin-9) already doesn't read that correctly and emits replacement characters.
The resulting XML is a mess, stating *explicitely* it's UTF-8, while containing
Latin-9.
In summary: Maven doesn't behave deterministically here, and depends on the
system environment where it shouldn't, leading to hard to find problems that
occur out of the blue for some developers only.
was (Author: jhermann):
Writing the result to a file doesn't really help (then the file's content
is broken, i.e. not well-formed XML). Consider this:
{code}
$ head -n1 pom.xml
?xml version=1.0?
$ grep -m1 name pom.xml | xxd
000: 2020 2020 3c6e 616d 653e 4d75 6c74 692d nameMulti-
010: 4172 6368 6574 7970 6573 2052 6f6f 7420 Archetypes Root
020: 504f 4d20 c3a4 c3b6 c3bc c39f 3c2f 6e61 POM /na
030: 6d65 3e0ame.
$ MAVEN_OPTS=-Dfile.encoding=iso-8859-15 mvn -Doutput=effective.xml
help:effective-pom
...
[INFO] Multi-Archetypes Root POM #65533;#65533;#65533;
...
$ head -n1 effective.xml
?xml version=1.0 encoding=UTF-8?
$ xmllint effective.xml
effective.xml:26: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xE4 0xF6 0xFC 0xDF
nameMulti-Archetypes Root POM #65533;#65533;#65533;#65533;/name
{code}
i.e. we have a pom.xml with default encoding (UTF-8) containing some properly
encoded umlauts (c3a4...). The Maven run (with simulating a system that uses
Latin-9) already doesn't read that correctly and emits replacement characters.
The resulting XML is a mess, stating *explicitely* it's UTF-8, while containing
Latin-9.
In summary: Maven doesn't behave deterministically here, and depends on the
system environment where it shouldn't, leading to hard to find problems that
occur out of the blue for some developers only.
help:effective-pom uses platform encoding and garbles non-ascii characters,
emits invalid XML
-
Key: MPH-87
URL: https://jira.codehaus.org/browse/MPH-87
Project: Maven 2.x Help Plugin
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Windows, MacOSX, Linux, Maven 3.0.4
Reporter: Mirko Friedenhagen
Attachments: mfriedenhagen-invalidpom-MPH-87-0-g42a5c31.zip
As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files
without a BOM and without a XML encoding declaration should read the XML as
UTF-8.
{{help:effective-pom}} does use the platform encoding for writing the
effective-pom without emitting an appropriate XML encoding declaration in the
resulting XML file.
I have created a small sample project (available at
https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will
reproduce the issue.
While the parent pom
(https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML
encoding declaration,
https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml
has none.
Now running:
{code}
mvn -s settings.xml -gs settings.xml clean validate
{code}
will produce an invalid character for the developer name Jörg in
{{child-invalid}}.
Two workarounds are:
* to include a XML encoding declaration as done in {{child-valid}}.
* to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in
[jira] (MCHECKSTYLE-176) Support for @javax.annotation.Generated
[
https://jira.codehaus.org/browse/MCHECKSTYLE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298612#comment-298612
]
Peter Ford commented on MCHECKSTYLE-176:
N.B. The difference between this (feature request in the
mvn-checkstyle-plugin) and the 'upstream' feature request
([2836054|http://sourceforge.net/tracker/?func=detailaid=2836054group_id=29721atid=397081])
could be that in the former case, the underlying checkstyle code would not
even _see_ any generated {{.java}} files, because Maven would exclude them.
Arguably, in the latter case, Checkstyle would look inside _every_ {{.java}}
file, and only ignore those program elements with the annotation. So
Checkstyle would still always process rules on parts of the file that can't be
annotated - such as import statements.
(Also, 2836054 is nearly 3 years old.)
Support for @javax.annotation.Generated
---
Key: MCHECKSTYLE-176
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-176
Project: Maven 2.x Checkstyle Plugin
Issue Type: New Feature
Reporter: Peter Ford
Priority: Minor
Would you be willing to consider whether any support can be added for
excluding code that is annotated with {{javax.annotation.Generated}}?
For example, if a {{.java}} file contains a public class that is annotated
{{@Generated}}, perhaps the whole file would be excluded from checks - if a
suitable parameter was set in the POM.
Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-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=298613#comment-298613
]
Geoffrey De Smet commented on MASSEMBLY-557:
@Christoph I 've found a possible workaround, can you check if it works for you
too?
{code}
dependencySet
...
!-- Workaround for https://jira.codehaus.org/browse/MASSEMBLY-557 --
fileMode755/fileMode
directoryMode755/directoryMode
unpacktrue/unpack
...
/dependencySet
{code}
I presume the bug is in
org.apache.maven.plugin.assembly.archive.task.AddArtifactTask#execute near
AddArtifactTask.java line 145:
{code}
if ( directoryMode != -1 )
{
archiver.setDirectoryMode( directoryMode );
dirModeSet = true;
}
{code}
I think the directoryMode (or the defaultDirectoryMode) should be set to a
default value anyway. Or that the Archiver from plexus-archiver should do that
automatically.
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 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-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=298616#comment-298616
]
Christoph Gritschenberger commented on MASSEMBLY-557:
-
Indeed that fixed it. Thanks a ton.
I added forced the directoryMode to 755 in the assembly-descriptor-section of
the corresponding directory and that was it.
{code}
diff --git a/assembly/src/descriptors/bin.xml b/assembly/src/descriptors/bin.xml
index 562c4db..c874142 100644
--- a/assembly/src/descriptors/bin.xml
+++ b/assembly/src/descriptors/bin.xml
@@ -98,6 +98,7 @@
outputDirectory/config//outputDirectory
lineEndingdos/lineEnding
fileMode0644/fileMode
+ directoryMode0755/directoryMode
/fileSet
!-- Copy openengsb system repo --
fileSet
{code}
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 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-353) Unit tests fail on Windows
Art O Cathain created MDEP-353: -- Summary: Unit tests fail on Windows Key: MDEP-353 URL: https://jira.codehaus.org/browse/MDEP-353 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.5 Environment: Windows 7, x86_64 Reporter: Art O Cathain Priority: Minor Attachments: build-windows.patch The TestGetMojo unit test of this plugin fail for me on Windows with org.apache.maven.plugin.MojoExecutionException: Couldn't download artifact: Unable to download the artifact from any repository The root cause is an IOException at AbstractWagon line 203: java.io.FileNotFoundException: [snip]maven-dependency-plugin\target\unit-tests\markers\org.apache.maven:maven-model:jar:2.0.9.tmp (The filename, directory name, or volume label syntax is incorrect) The StubArtifactRepository is trying to create a file with a colon in it, and Windows doesn't like that. See attached patch for a possible fix. It might be better to fix StubArtifactRepository in the maven-plugin-testing-harness but I'm a little nervous of breaking other plugin builds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-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=298613#comment-298613
]
Geoffrey De Smet edited comment on MASSEMBLY-557 at 5/14/12 9:04 AM:
-
@Christoph I 've found a possible workaround, can you check if it works for you
too?
{code}
dependencySet
...
!-- Workaround for https://jira.codehaus.org/browse/MASSEMBLY-557 --
fileMode755/fileMode
directoryMode755/directoryMode
unpacktrue/unpack
...
/dependencySet
{code}
was (Author: ge0ffrey):
@Christoph I 've found a possible workaround, can you check if it works for
you too?
{code}
dependencySet
...
!-- Workaround for https://jira.codehaus.org/browse/MASSEMBLY-557 --
fileMode755/fileMode
directoryMode755/directoryMode
unpacktrue/unpack
...
/dependencySet
{code}
I presume the bug is in
org.apache.maven.plugin.assembly.archive.task.AddArtifactTask#execute near
AddArtifactTask.java line 145:
{code}
if ( directoryMode != -1 )
{
archiver.setDirectoryMode( directoryMode );
dirModeSet = true;
}
{code}
I think the directoryMode (or the defaultDirectoryMode) should be set to a
default value anyway. Or that the Archiver from plexus-archiver should do that
automatically.
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 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-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=298644#comment-298644
]
Geoffrey De Smet commented on MASSEMBLY-557:
SUMMARY of the issue: *the assembly zip is randomly corrupted if dependenySet
together with unziptrue/ is used without explicitly setting the
directoryMode.../*.
I presume the bug is in
org.apache.maven.plugin.assembly.archive.task.AddArtifactTask#execute near
AddArtifactTask.java line 145:
{code}
if ( directoryMode != -1 )
{
archiver.setDirectoryMode( directoryMode );
dirModeSet = true;
}
{code}
I think the directoryMode (or the defaultDirectoryMode) should be set to a
default value anyway. Or that the Archiver from plexus-archiver should do that
automatically.
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 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Geoffrey De Smet
Priority: Critical
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5285) New profile activation based on SNAPSHOT qualifier
Paul Benedict created MNG-5285: -- Summary: New profile activation based on SNAPSHOT qualifier Key: MNG-5285 URL: https://jira.codehaus.org/browse/MNG-5285 Project: Maven 2 3 Issue Type: Improvement Components: Profiles Affects Versions: 3.0.4 Reporter: Paul Benedict Priority: Minor Although writing a ProfileActivator will do, I think this should be built into Maven. We only want to activate a plugin when the artifact is a SNAPSHOT. It's an additional build check that we don't need when releasing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-757) cannot perform a release with another pom then pom.xml
[
https://jira.codehaus.org/browse/MRELEASE-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-757:
Description:
If for an obscure but uncontrolable reason I hava a pom named anything else
then {{pom.xml}}, like {{pom2.xml}}, the following command don't work :
{{mvn -f pom2.xml release:prepare release:perform}}
the prepare phase works well. But the perform have this error : the deploy
command launched on the checked out code (in the target folder) run with
pom.xml... I fixed it with the following code change :
{code:title=RunPerformGoalsPhase.java, line 71}
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f pom.xml;
}
else
{
additionalArguments = -f pom.xml;
}
{code}
with :
{code}
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f + pomFileName;
}
else
{
additionalArguments = -f + pomFileName;
}
{code}
was:
If for an obscure but uncontrolable reason I hava a pom named anything else
then pom.xml, like pom2.xml, the following command don't work :
mvn -f pom2.xml release:prepare release:perform
the prepare phase works well. But the perform have this error : the deploy
command launched on the checked out code (in the target folder) run with
pom.xml... I fixed it with the following code change :
RunPerformGoalsPhase.java, line 71 :
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f pom.xml;
}
else
{
additionalArguments = -f pom.xml;
}
with :
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f + pomFileName;
}
else
{
additionalArguments = -f + pomFileName;
}
Patch Submitted: (was: Yes)
Affects Version/s: 2.3
cannot perform a release with another pom then pom.xml
--
Key: MRELEASE-757
URL: https://jira.codehaus.org/browse/MRELEASE-757
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.3
Reporter: Emmanuel Potvin
If for an obscure but uncontrolable reason I hava a pom named anything else
then {{pom.xml}}, like {{pom2.xml}}, the following command don't work :
{{mvn -f pom2.xml release:prepare release:perform}}
the prepare phase works well. But the perform have this error : the deploy
command launched on the checked out code (in the target folder) run with
pom.xml... I fixed it with the following code change :
{code:title=RunPerformGoalsPhase.java, line 71}
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f pom.xml;
}
else
{
additionalArguments = -f pom.xml;
}
{code}
with :
{code}
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f + pomFileName;
}
else
{
additionalArguments = -f + pomFileName;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-757) cannot perform a release with another pom then pom.xml
[
https://jira.codehaus.org/browse/MRELEASE-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-757.
---
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Robert Scholte
Fixed in [r1338367|http://svn.apache.org/viewvc?rev=1338367view=rev]
ps. It would be nice if you could provide a real patch next time. See the
[Maven development
guide|http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patch]
or examine your IDE, they all have good support for creating patches.
cannot perform a release with another pom then pom.xml
--
Key: MRELEASE-757
URL: https://jira.codehaus.org/browse/MRELEASE-757
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.3
Reporter: Emmanuel Potvin
Assignee: Robert Scholte
Fix For: 2.4
If for an obscure but uncontrolable reason I hava a pom named anything else
then {{pom.xml}}, like {{pom2.xml}}, the following command don't work :
{{mvn -f pom2.xml release:prepare release:perform}}
the prepare phase works well. But the perform have this error : the deploy
command launched on the checked out code (in the target folder) run with
pom.xml... I fixed it with the following code change :
{code:title=RunPerformGoalsPhase.java, line 71}
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f pom.xml;
}
else
{
additionalArguments = -f pom.xml;
}
{code}
with :
{code}
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f + pomFileName;
}
else
{
additionalArguments = -f + pomFileName;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-725) Releasing a specific module-based project fails (Regression from 2.1)
[ https://jira.codehaus.org/browse/MRELEASE-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298678#comment-298678 ] Robert Scholte commented on MRELEASE-725: - @Philipp, could you try this with the maven-release-plugin version 2.3? This version contains some fixes related to the path of the working directory. Releasing a specific module-based project fails (Regression from 2.1) - Key: MRELEASE-725 URL: https://jira.codehaus.org/browse/MRELEASE-725 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.2, 2.2.1, 2.2.2 Environment: Mac OS X 10.7.2 Apache Maven 3.0.3 Subversion 1.6.16 (r1073529) Reporter: Philipp Paland Attachments: transscript.txt, trunk.zip We can not release our project with a version of the release plugin greater than 2.1. I have distilled the problem to a small example project (attached as zip). The project has a core module (with code) and an aggregating build project, like this: - build - release - pom.xml - core - hello-world - pom.xml - src/main/java/HelloWorld.java where hello-world is a module of release. It looks like release:perform tries to build in the wrong directory: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.2:perform (default-cli) on project release: Error executing Maven. Working directory /Development/maven-release-bug/trunk/build/release/target/checkout/build/release/build/release does not exist! - [Help 1] I have also attached a transscript with some easy steps to reproduce the problem. First, a local svn repo is created. Then, the working release with 2.1 is demonstrated. Then the plugin version in the pom is changed and the error is shown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-757) cannot perform a release with another pom then pom.xml
[
https://jira.codehaus.org/browse/MRELEASE-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298679#comment-298679
]
Emmanuel Potvin commented on MRELEASE-757:
--
Noted. You're welcome by the way.
cannot perform a release with another pom then pom.xml
--
Key: MRELEASE-757
URL: https://jira.codehaus.org/browse/MRELEASE-757
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.3
Reporter: Emmanuel Potvin
Assignee: Robert Scholte
Fix For: 2.4
If for an obscure but uncontrolable reason I hava a pom named anything else
then {{pom.xml}}, like {{pom2.xml}}, the following command don't work :
{{mvn -f pom2.xml release:prepare release:perform}}
the prepare phase works well. But the perform have this error : the deploy
command launched on the checked out code (in the target folder) run with
pom.xml... I fixed it with the following code change :
{code:title=RunPerformGoalsPhase.java, line 71}
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f pom.xml;
}
else
{
additionalArguments = -f pom.xml;
}
{code}
with :
{code}
// ensure we don't use the release pom for the perform goals
if ( !StringUtils.isEmpty( additionalArguments ) )
{
additionalArguments = additionalArguments + -f + pomFileName;
}
else
{
additionalArguments = -f + pomFileName;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-603) Allow configuration of goals to be executed after release creation
[
https://jira.codehaus.org/browse/MRELEASE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=298685#comment-298685
]
Robert Scholte commented on MRELEASE-603:
-
The {{perform}}-goal is about checking out the project by the release-tag and
run several release-goals on that projects, usualy {{deploy}} and
{{deploy-site}}.
Your goal is to have the pom.xml ready for the next development-cycle, which
should be part of the {{prepare}}-goal.
I think that a post-perform goal wouldn't help.
Correct me if I'm wrong, but this is how I read your story:
In this order the projects have been released:
* shared-1
* earA-1 (using shared-1)
* earB-1 (using shared-1)
* shared-2
* earA-2 (using shared-2)
* earA-3 (using shared-2)
* shared-3
Now we want to release earB-2, which probably depends on shared-2-SNAPSHOT (not
the latest snapshot) since earB-1 was released before shared-2.
You probably want this release to use shared-3.
So it seems like you've developed with the wrong snapshot version, and no
post-goal would have helped here.
I'd prefer not to use a fully automated call of {{use-latest-version}}, but
that's something a CI-system could do for you. Also think of the checkin, which
has to follow.
Allow configuration of goals to be executed after release creation
--
Key: MRELEASE-603
URL: https://jira.codehaus.org/browse/MRELEASE-603
Project: Maven 2.x Release Plugin
Issue Type: New Feature
Affects Versions: 2.1
Reporter: Marcus Linke
Assignee: Robert Scholte
Priority: Minor
It would be nice if the release plugin allows the configuration of some goals
to be executed after the release creation. This could be used for example to
configure the automatic execution of the maven-versions-plugin to update the
dependencies versions of the newly created snaphot.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-130) Strange difference between enforcer dependency convergence and dependency tree (hibernate4/jboss-logging)
leif hanack created MENFORCER-130: - Summary: Strange difference between enforcer dependency convergence and dependency tree (hibernate4/jboss-logging) Key: MENFORCER-130 URL: https://jira.codehaus.org/browse/MENFORCER-130 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.0.1 Environment: MacOSX Linux RedHead Reporter: leif hanack Hi there, I'm a bit lost. We are using Hibernate4. Unfortunately they mixed up their dependencies a bit, so that we managed them in our pom: dependency groupIdorg.jboss.logging/groupId artifactIdjboss-logging/artifactId version3.1.0.GA/version /dependency The dependency tree looks good. The dependency jboss-logging 3.1.0.CR2 is overwritten by the above definition: [INFO] | \- ourgroup:nic-api:jar:103:compile [INFO] | +- ourgroup:persistence:jar:2.22-Hibernate4:compile [INFO] | | +- org.springframework:spring-test:jar:3.1.1.RELEASE:compile [INFO] | | +- javax.annotation:jsr250-api:jar:1.0:compile [INFO] | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile - omitted for duplicate) [INFO] | | +- de.hypoport.ef2:ef2-core:jar:2.22-Hibernate4:compile [INFO] | | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile - omitted for duplicate) [INFO] | | | \- org.springframework:spring-context:jar:3.1.1.RELEASE:compile [INFO] | | | +- (org.springframework:spring-beans:jar:3.1.1.RELEASE:compile - omitted for duplicate) [INFO] | | | \- org.springframework:spring-expression:jar:3.1.1.RELEASE:compile [INFO] | | +- org.hibernate:hibernate-core:jar:4.1.2.Final:compile [INFO] | | | +- org.jboss.logging:jboss-logging:jar:3.1.0.GA:compile [INFO] | | | +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:compile [INFO] | | | +- dom4j:dom4j:jar:1.6.1:compile [INFO] | | | +- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.1.Final:compile [INFO] | | | +- org.javassist:javassist:jar:3.15.0-GA:compile [INFO] | | | \- org.hibernate.common:hibernate-commons-annotations:jar:4.0.1.Final:compile [INFO] | | | \- (org.jboss.logging:jboss-logging:jar:3.1.0.CR2:compile - omitted for conflict with 3.1.0.GA) Running the enforcer rule DependencyConvergence results in an error: [ERROR] Dependency convergence error for org.jboss.logging:jboss-logging:3.1.0.GA paths to dependency are: +-ourgroup:rules-assembly:11-SNAPSHOT +-ourgroup:scoring:139 +-ourgroup:nic-api:103 +-ourgroup:persistence:2.22-Hibernate4 +-org.hibernate:hibernate-core:4.1.2.Final +-org.jboss.logging:jboss-logging:3.1.0.GA and +-ourgroup:rules-assembly:11-SNAPSHOT +-ourgroup:scoring:139 +-ourgroup:nic-api:103 +-ourgroup:persistence:2.22-Hibernate4 +-org.hibernate:hibernate-core:4.1.2.Final +-org.hibernate.common:hibernate-commons-annotations:4.0.1.Final +-org.jboss.logging:jboss-logging:3.1.0.CR2 This feels unexpected. Is this a bug, or do I understand s.th. wrong:) Thanks a lot, Leif -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
