[jira] (MASSEMBLY-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
Joseph Walton created MASSEMBLY-595:
---
Summary: Tar file contains world-writeable files when fileSets
with and without fileMode are mixed
Key: MASSEMBLY-595
URL: https://jira.codehaus.org/browse/MASSEMBLY-595
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Joseph Walton
I have an assembly descriptor with some fileSets that do and some that don't
set the fileMode. Any resources after fileMode has been set end up with
world-writable permissions.
This assembly descriptor:
{code}
dist
tar.gz
src/main/files
a
src/main/files
b
0744
src/main/files
c
{code}
gives:
{code}
$ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
-rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
-rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
-rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
{code}
The third copy of the fileSet, with no {{fileMode}} set, is now world-writable,
unlike the first. The second directory, with no {{directoryMode}} specified,
has the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
[
https://jira.codehaus.org/browse/MASSEMBLY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MASSEMBLY-595:
Attachment: MASSEMBLY-595.tar.gz
> Tar file contains world-writeable files when fileSets with and without
> fileMode are mixed
> -
>
> Key: MASSEMBLY-595
> URL: https://jira.codehaus.org/browse/MASSEMBLY-595
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Joseph Walton
> Attachments: MASSEMBLY-595.tar.gz
>
>
> I have an assembly descriptor with some fileSets that do and some that don't
> set the fileMode. Any resources after fileMode has been set end up with
> world-writable permissions.
> This assembly descriptor:
> {code}
>
> dist
>
> tar.gz
>
>
>
> src/main/files
> a
>
>
> src/main/files
> b
> 0744
>
>
> src/main/files
> c
>
>
>
> {code}
> gives:
> {code}
> $ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
> drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
> -rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
> drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
> -rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
> drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
> -rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
> {code}
> The third copy of the fileSet, with no {{fileMode}} set, is now
> world-writable, unlike the first. The second directory, with no
> {{directoryMode}} specified, has the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287511#comment-287511
]
Anthony BOUQUET commented on MRELEASE-511:
--
Same issue here, I understand that versions number should be logical but the
plugin should be less restrictif on the first argument before the first dot.
Versions like XXX.0.1 (with XXX alphanumerical) should be parsed correctly
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: https://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Priority: Critical
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
>
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository central (http://repo1.maven.org/maven2)
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d
> :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
> [INFO] Working directory: C:\workspaces\head\MyClient
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error parsing version, cannot determine next version: Unable to parse
> the version string: "MYB_200909-SNAPSHOT"
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
> version, cannot determine next version: Unable to parse the version string:
> "MYB_200909-SNAPSHOT"
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodA
[jira] (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287511#comment-287511
]
Anthony BOUQUET edited comment on MRELEASE-511 at 1/5/12 7:58 AM:
--
Same issue here, I understand that versions number should be logical but the
plugin should be less restrictif on the first argument before the first dot.
Versions like XXX.0.1 (with XXX alphanumerical) should be parsed correctly
Edit : Maven version 2.2.1, maven-release-plugin 2.2.1
was (Author: globule71):
Same issue here, I understand that versions number should be logical but
the plugin should be less restrictif on the first argument before the first dot.
Versions like XXX.0.1 (with XXX alphanumerical) should be parsed correctly
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: https://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Priority: Critical
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
>
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository central (http://repo1.maven.org/maven2)
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d
> :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
> [INFO] Working directory: C:\workspaces\head\MyClient
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error parsing version, cannot determine next version: Unable to parse
> the version string: "MYB_200909-SNAPSHOT"
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
> version, cannot determine next version: Unable to parse the version string:
> "MYB_200909-SNAPSHOT"
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.D
[jira] (MASSEMBLY-580) dependencySet ignores directoryMode descriptor
[ https://jira.codehaus.org/browse/MASSEMBLY-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287535#comment-287535 ] Antonio García commented on MASSEMBLY-580: -- I have experienced the same regression with 2.2.1 and 2.2.2. 2.2-beta-2 and 2.2-beta-3 do not have this problem. It seems that the regression first appeared with 2.2-beta-4. > dependencySet ignores directoryMode descriptor > -- > > Key: MASSEMBLY-580 > URL: https://jira.codehaus.org/browse/MASSEMBLY-580 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Johno Crawford > Attachments: directoryModeIgnored.zip > > > Despite having set the directoryMode for the dependencySet the permissions > are ignored and the folder is set to 777 which poses as a possible security > risk. Please find attached project which can be used to create the test zip > containing the folder with incorrect permissions. > $ unzip project-deploy.zip > Archive: project-deploy.zip >creating: webapps/ > inflating: webapps/commons-fileupload.jar > $ ls -lah > total 92K > drwxr-xr-x 4 johno sulake 4.0K Oct 27 20:26 . > drwxr-xr-x 4 johno sulake 4.0K Oct 27 20:25 .. > drwxr-xr-x 2 johno sulake 4.0K Oct 27 20:25 archive-tmp > -rw-r--r-- 1 johno sulake 51K Oct 27 20:25 project-deploy.zip > drwxrwxrwx 2 johno sulake 4.0K Oct 27 20:25 webapps > Thanks in advance! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-817) JUnit 4.7 test output is always buffered, lost if forked process exits abnormally
Todd Lipcon created SUREFIRE-817: Summary: 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-814) Parallel "both" setting does not execute classes in parallel
[ https://jira.codehaus.org/browse/SUREFIRE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287547#comment-287547 ] Quantum Mechanics commented on SUREFIRE-814: I understand your comment above above about the future of this functionality. Can you please confirm that the behavior I observed the current operation of 'both'? I just want to make sure that this is not due to my version of surefire, some config issue or misinterpretation of the output. Thanks. > Parallel "both" setting does not execute classes in parallel > > > Key: SUREFIRE-814 > URL: https://jira.codehaus.org/browse/SUREFIRE-814 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.11 >Reporter: Quantum Mechanics > > jdk 1.6.0_22, windows XP -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287554#comment-287554 ] Stanilslav Spiridonov commented on MNG-624: --- I have one idea. The main point of parent POM is collect all similar modules settings (property, dependency, plugins, etc.) in one place (with possible hierarchy) and make the DEVELOPMENT of project with multiple project more simple. All these have sense only on source level. After the build and install/deploy artifact to local or remote repository the parents poms only produce complications without any additional value (is not?). So my suggestion install deploy artifacts with effective POM, now the real. So the parent poms will exist only on source level and disappear in produced artifact. It is backward compatible with current implementation and will not break anything in existing projects. May be is is stupid, but I believe it will simplify the issue with parent POM and will allow to find the right solution. For example after that the SNAPSHOTS artifact will not refereeing the SNAPSHOT parent, so even SNAPSHOTS will be more fixed and stable. > automatic parent versioning > --- > > Key: MNG-624 > URL: https://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.1 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287554#comment-287554 ] Stanilslav Spiridonov edited comment on MNG-624 at 1/5/12 4:40 PM: --- I have one idea. The main point of parent POM is collect all similar modules settings (property, dependency, plugins, etc.) in one place (with possible hierarchy) and make the DEVELOPMENT of project with multiple project more simple. All these have sense only on source level. After the build and install/deploy artifact to local or remote repository the parents poms only produce complications without any additional value (is not?). So my suggestion is to install/deploy artifacts with effective POM, now the real one. So the parent pom will exist only on source level and disappear in produced artifact. It is backward compatible with current implementation and will not break anything in existing projects. May be is is stupid, but I believe it will simplify the issue with parent POM and will allow to find the right solution. For example after that the SNAPSHOTS artifact will not refereeing the SNAPSHOT parent, so even SNAPSHOTS will be more fixed and stable. was (Author: foal): I have one idea. The main point of parent POM is collect all similar modules settings (property, dependency, plugins, etc.) in one place (with possible hierarchy) and make the DEVELOPMENT of project with multiple project more simple. All these have sense only on source level. After the build and install/deploy artifact to local or remote repository the parents poms only produce complications without any additional value (is not?). So my suggestion install deploy artifacts with effective POM, now the real. So the parent poms will exist only on source level and disappear in produced artifact. It is backward compatible with current implementation and will not break anything in existing projects. May be is is stupid, but I believe it will simplify the issue with parent POM and will allow to find the right solution. For example after that the SNAPSHOTS artifact will not refereeing the SNAPSHOT parent, so even SNAPSHOTS will be more fixed and stable. > automatic parent versioning > --- > > Key: MNG-624 > URL: https://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.1 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-219) Maven3 LinkageError in maven report
[
https://jira.codehaus.org/browse/MSHARED-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Wipplinger updated MSHARED-219:
---
Attachment: MSHARED-219.patch
> Maven3 LinkageError in maven report
> ---
>
> Key: MSHARED-219
> URL: https://jira.codehaus.org/browse/MSHARED-219
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-exec
>Affects Versions: maven-reporting-exec-1.0.1
> Environment: [INFO] Maven Version: 3.0.3
> [INFO] JDK Version: 1.6.0_26 normalized as: 1.6.0-26
> [INFO] OS Info: Arch: amd64 Family: unix Name: linux Version:
> 2.6.32-37-generic
>Reporter: Gerhard Wipplinger
> Attachments: MSHARED-219.patch
>
>
> Creating a maven report using some kind of a filter sink:
> public class DoxiaTestMojo extends AbstractMavenReport {
> ...
> @Override
> protected void executeReport(Locale locale) throws
> MavenReportException {
> org.apache.maven.doxia.sink.Sink s = new SinkAdapter() {
> ...
> };
> ...
> }
> }
> produces the following error:
> [WARNING] An issue has occurred with report at.gw.test.DoxiaTestMojo,
> skip LinkageError loader constraint violation in interface itable
> initialization: when resolving method
> "org.apache.maven.doxia.sink.AbstractSink.enableLogging(Lorg/apache/maven/doxia/logging/Log;)V"
> the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class,
> org/apache/maven/doxia/sink/AbstractSink, and the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) for interface
> org/apache/maven/doxia/logging/LogEnabled have different Class objects for
> the type org/apache/maven/doxia/logging/Log used in the signature, please
> report an issue to Maven dev team.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-219) Maven3 LinkageError in maven report
Gerhard Wipplinger created MSHARED-219:
--
Summary: Maven3 LinkageError in maven report
Key: MSHARED-219
URL: https://jira.codehaus.org/browse/MSHARED-219
Project: Maven Shared Components
Issue Type: Bug
Components: maven-reporting-exec
Affects Versions: maven-reporting-exec-1.0.1
Environment: [INFO] Maven Version: 3.0.3
[INFO] JDK Version: 1.6.0_26 normalized as: 1.6.0-26
[INFO] OS Info: Arch: amd64 Family: unix Name: linux Version: 2.6.32-37-generic
Reporter: Gerhard Wipplinger
Attachments: MSHARED-219.patch
Creating a maven report using some kind of a filter sink:
public class DoxiaTestMojo extends AbstractMavenReport {
...
@Override
protected void executeReport(Locale locale) throws
MavenReportException {
org.apache.maven.doxia.sink.Sink s = new SinkAdapter() {
...
};
...
}
}
produces the following error:
[WARNING] An issue has occurred with report at.gw.test.DoxiaTestMojo,
skip LinkageError loader constraint violation in interface itable
initialization: when resolving method
"org.apache.maven.doxia.sink.AbstractSink.enableLogging(Lorg/apache/maven/doxia/logging/Log;)V"
the class loader (instance of
org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class,
org/apache/maven/doxia/sink/AbstractSink, and the class loader (instance of
org/codehaus/plexus/classworlds/realm/ClassRealm) for interface
org/apache/maven/doxia/logging/LogEnabled have different Class objects for the
type org/apache/maven/doxia/logging/Log used in the signature, please report an
issue to Maven dev team.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-219) Maven3 LinkageError in maven report
[
https://jira.codehaus.org/browse/MSHARED-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287555#comment-287555
]
Gerhard Wipplinger commented on MSHARED-219:
All current ITs of the maven-site-plugin pass. A new IT for the
maven-site-plugin is missing.
> Maven3 LinkageError in maven report
> ---
>
> Key: MSHARED-219
> URL: https://jira.codehaus.org/browse/MSHARED-219
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-exec
>Affects Versions: maven-reporting-exec-1.0.1
> Environment: [INFO] Maven Version: 3.0.3
> [INFO] JDK Version: 1.6.0_26 normalized as: 1.6.0-26
> [INFO] OS Info: Arch: amd64 Family: unix Name: linux Version:
> 2.6.32-37-generic
>Reporter: Gerhard Wipplinger
> Attachments: MSHARED-219.patch
>
>
> Creating a maven report using some kind of a filter sink:
> public class DoxiaTestMojo extends AbstractMavenReport {
> ...
> @Override
> protected void executeReport(Locale locale) throws
> MavenReportException {
> org.apache.maven.doxia.sink.Sink s = new SinkAdapter() {
> ...
> };
> ...
> }
> }
> produces the following error:
> [WARNING] An issue has occurred with report at.gw.test.DoxiaTestMojo,
> skip LinkageError loader constraint violation in interface itable
> initialization: when resolving method
> "org.apache.maven.doxia.sink.AbstractSink.enableLogging(Lorg/apache/maven/doxia/logging/Log;)V"
> the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class,
> org/apache/maven/doxia/sink/AbstractSink, and the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) for interface
> org/apache/maven/doxia/logging/LogEnabled have different Class objects for
> the type org/apache/maven/doxia/logging/Log used in the signature, please
> report an issue to Maven dev team.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-219) Maven3 LinkageError in maven report
[
https://jira.codehaus.org/browse/MSHARED-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MSHARED-219:
-
Fix Version/s: maven-reporting-exec-1.1
Assignee: Olivier Lamy
> Maven3 LinkageError in maven report
> ---
>
> Key: MSHARED-219
> URL: https://jira.codehaus.org/browse/MSHARED-219
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-exec
>Affects Versions: maven-reporting-exec-1.0.1
> Environment: [INFO] Maven Version: 3.0.3
> [INFO] JDK Version: 1.6.0_26 normalized as: 1.6.0-26
> [INFO] OS Info: Arch: amd64 Family: unix Name: linux Version:
> 2.6.32-37-generic
>Reporter: Gerhard Wipplinger
>Assignee: Olivier Lamy
> Fix For: maven-reporting-exec-1.0.2
>
> Attachments: MSHARED-219.patch
>
>
> Creating a maven report using some kind of a filter sink:
> public class DoxiaTestMojo extends AbstractMavenReport {
> ...
> @Override
> protected void executeReport(Locale locale) throws
> MavenReportException {
> org.apache.maven.doxia.sink.Sink s = new SinkAdapter() {
> ...
> };
> ...
> }
> }
> produces the following error:
> [WARNING] An issue has occurred with report at.gw.test.DoxiaTestMojo,
> skip LinkageError loader constraint violation in interface itable
> initialization: when resolving method
> "org.apache.maven.doxia.sink.AbstractSink.enableLogging(Lorg/apache/maven/doxia/logging/Log;)V"
> the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class,
> org/apache/maven/doxia/sink/AbstractSink, and the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) for interface
> org/apache/maven/doxia/logging/LogEnabled have different Class objects for
> the type org/apache/maven/doxia/logging/Log used in the signature, please
> report an issue to Maven dev team.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-219) Maven3 LinkageError in maven report
[
https://jira.codehaus.org/browse/MSHARED-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MSHARED-219.
Resolution: Fixed
fixed r1227894.
Thanks
> Maven3 LinkageError in maven report
> ---
>
> Key: MSHARED-219
> URL: https://jira.codehaus.org/browse/MSHARED-219
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-exec
>Affects Versions: maven-reporting-exec-1.0.1
> Environment: [INFO] Maven Version: 3.0.3
> [INFO] JDK Version: 1.6.0_26 normalized as: 1.6.0-26
> [INFO] OS Info: Arch: amd64 Family: unix Name: linux Version:
> 2.6.32-37-generic
>Reporter: Gerhard Wipplinger
>Assignee: Olivier Lamy
> Fix For: maven-reporting-exec-1.0.2
>
> Attachments: MSHARED-219.patch
>
>
> Creating a maven report using some kind of a filter sink:
> public class DoxiaTestMojo extends AbstractMavenReport {
> ...
> @Override
> protected void executeReport(Locale locale) throws
> MavenReportException {
> org.apache.maven.doxia.sink.Sink s = new SinkAdapter() {
> ...
> };
> ...
> }
> }
> produces the following error:
> [WARNING] An issue has occurred with report at.gw.test.DoxiaTestMojo,
> skip LinkageError loader constraint violation in interface itable
> initialization: when resolving method
> "org.apache.maven.doxia.sink.AbstractSink.enableLogging(Lorg/apache/maven/doxia/logging/Log;)V"
> the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) of the current class,
> org/apache/maven/doxia/sink/AbstractSink, and the class loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm) for interface
> org/apache/maven/doxia/logging/LogEnabled have different Class objects for
> the type org/apache/maven/doxia/logging/Log used in the signature, please
> report an issue to Maven dev team.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-627) upgrade to reporting-exec 1.0.2
Olivier Lamy created MSITE-627: -- Summary: upgrade to reporting-exec 1.0.2 Key: MSITE-627 URL: https://jira.codehaus.org/browse/MSITE-627 Project: Maven 2.x and 3.x Site Plugin Issue Type: Improvement Reporter: Olivier Lamy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-627) upgrade to reporting-exec 1.0.2
[ https://jira.codehaus.org/browse/MSITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSITE-627: --- Fix Version/s: 3.1 Assignee: Olivier Lamy > upgrade to reporting-exec 1.0.2 > --- > > Key: MSITE-627 > URL: https://jira.codehaus.org/browse/MSITE-627 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > -- 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] [Commented] (MPOM-32) Apache POM 10 forces all child projects to generate the project info reports
[ https://issues.apache.org/jira/browse/MPOM-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180986#comment-13180986 ] Sebb commented on MPOM-32: -- PING > Apache POM 10 forces all child projects to generate the project info reports > > > Key: MPOM-32 > URL: https://issues.apache.org/jira/browse/MPOM-32 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-10 >Reporter: Sebb >Priority: Blocker > > One of the changes between ASF-9 and ASF-10 was to configure > maven-project-info-reports-plugin with a full set of reports. > This means that all inheriting projects now get the full set of reports, > whether they want them or not. > Note that this feature is not documented on the overview page [1] > The other changes in 10 seem benign. > [1] http://maven.apache.org/pom/asf/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-272) META-INF is not excluded for war overlay collected via a dependency
Benson Margulies created MWAR-272: - Summary: META-INF is not excluded for war overlay collected via a dependency Key: MWAR-272 URL: https://jira.codehaus.org/browse/MWAR-272 Project: Maven 2.x WAR Plugin Issue Type: Bug Components: overlay Affects Versions: 2.1.1 Reporter: Benson Margulies In my pom, I list a war as a dependency and offer no configuration of . The META-INF of the overlay war turns up: ./r4dws-service/target/war/work/com.basistech/web-service-jquery-ui/META-INF/maven/com.basistech/web-service-jquery-ui/pom.xml which is contrary to the documentation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-272) META-INF is not excluded for war overlay collected via a dependency
[ https://jira.codehaus.org/browse/MWAR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MWAR-272. - Resolution: Not A Bug Assignee: Benson Margulies Stupidity. I was looking at the 'work' directory. > META-INF is not excluded for war overlay collected via a dependency > --- > > Key: MWAR-272 > URL: https://jira.codehaus.org/browse/MWAR-272 > Project: Maven 2.x WAR Plugin > Issue Type: Bug > Components: overlay >Affects Versions: 2.1.1 >Reporter: Benson Margulies >Assignee: Benson Margulies > > In my pom, I list a war as a dependency and offer no configuration of > . The META-INF of the overlay war turns up: > ./r4dws-service/target/war/work/com.basistech/web-service-jquery-ui/META-INF/maven/com.basistech/web-service-jquery-ui/pom.xml > which is contrary to the documentation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-595) Tar file contains world-writeable files when fileSets with and without fileMode are mixed
[
https://jira.codehaus.org/browse/MASSEMBLY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287571#comment-287571
]
Joseph Walton commented on MASSEMBLY-595:
-
Caused by [PLXCOMP-196|https://jira.codehaus.org/browse/PLXCOMP-196] and
[PLXCOMP-197|https://jira.codehaus.org/browse/PLXCOMP-197].
> Tar file contains world-writeable files when fileSets with and without
> fileMode are mixed
> -
>
> Key: MASSEMBLY-595
> URL: https://jira.codehaus.org/browse/MASSEMBLY-595
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Joseph Walton
> Attachments: MASSEMBLY-595.tar.gz
>
>
> I have an assembly descriptor with some fileSets that do and some that don't
> set the fileMode. Any resources after fileMode has been set end up with
> world-writable permissions.
> This assembly descriptor:
> {code}
>
> dist
>
> tar.gz
>
>
>
> src/main/files
> a
>
>
> src/main/files
> b
> 0744
>
>
> src/main/files
> c
>
>
>
> {code}
> gives:
> {code}
> $ tar tvvf target/test-1-SNAPSHOT-dist.tar.gz
> drwxr-xr-x jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/
> -rw-r--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/a/empty-file
> drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/
> -rwxr--r-- jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/b/empty-file
> drwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/
> -rwxrwxrwx jwalton/jwalton 0 2012-01-05 18:55 test-1-SNAPSHOT/c/empty-file
> {code}
> The third copy of the fileSet, with no {{fileMode}} set, is now
> world-writable, unlike the first. The second directory, with no
> {{directoryMode}} specified, has the same problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-590) Upgrade plexus dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Walton updated MASSEMBLY-590:
Attachment: MASSEMBLY-590.diff
> Upgrade plexus dependencies
> ---
>
> Key: MASSEMBLY-590
> URL: https://jira.codehaus.org/browse/MASSEMBLY-590
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Reporter: Odd Vinje
> Attachments: MASSEMBLY-590.diff
>
>
> The plexus dependencies used internally are outdated. There are major issues
> with plexus-io version 1.x (one example:
> http://jira.codehaus.org/browse/PLXCOMP-149)
> The assembly plugin uses plexus-io 1.0.1, but the latest is 2.0.1.
> {code}
> [INFO] --- maven-assembly-plugin:2.2.1:single (attach-artifacts) ---
> [DEBUG]org.codehaus.plexus:plexus-io:jar:1.0.1:compile
> {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] (SUREFIRE-814) Parallel "both" setting does not execute classes in parallel
[ https://jira.codehaus.org/browse/SUREFIRE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287583#comment-287583 ] Kristian Rosenvold commented on SUREFIRE-814: - "both" is largely untested for a long time and I have no reason to disbelieve that you're seeing this issue. > Parallel "both" setting does not execute classes in parallel > > > Key: SUREFIRE-814 > URL: https://jira.codehaus.org/browse/SUREFIRE-814 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.11 >Reporter: Quantum Mechanics > > jdk 1.6.0_22, windows XP -- 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-5225) The default version of the maven-site-plugin as defined in the site-lifecycle must be 3.x
[ https://jira.codehaus.org/browse/MNG-5225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287590#comment-287590 ] Anders Hammar commented on MNG-5225: This is a duplicate of MNG-5221. > The default version of the maven-site-plugin as defined in the site-lifecycle > must be 3.x > - > > Key: MNG-5225 > URL: https://jira.codehaus.org/browse/MNG-5225 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Robert Scholte >Assignee: Olivier Lamy > Fix For: 3.0.4 > > > http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml?view=markup#l116 > The version still refers to 2.0.1, which it not compatible with Maven3 -- 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
