[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-tabpanel&focusedCommentId=354113#comment-354113
]
Herve Boutemy edited comment on MSITE-604 at 10/10/14 1:04 AM:
---
@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 you look at my previous question: I can't reproduce your problem
if I can't see any problem, I can't fix anything
was (Author: hboutemy):
@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}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {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 {{ 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] (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}
>
>
> jars-with-dependencies
>
> jar
>
> false
>
>
> ${project.build.outputDirectory}
> /
>
>
>
>
> /
> true
>
> *:jar:*
>
>
>
>
> {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)
[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-tabpanel&focusedCommentId=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-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] (MASSEMBLY-588) Build fails because of 'ls -1nlaR /'
[ https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > 2>&1 | tee log': > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2:37.924s > [INFO] Finished at: Tue Dec 06 20:30:47 CET 2011 > [INFO] Final Memory: 8M/216M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error creating assembly archive bin: Failed to retrieve numeric > file attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:504) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error creating assembly archive bin: Failed to retrieve numeric file > attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiv
[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 > 2>&1 | tee log': > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2:37.924s > [INFO] Finished at: Tue Dec 06 20:30:47 CET 2011 > [INFO] Final Memory: 8M/216M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error creating assembly archive bin: Failed to retrieve numeric > file attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:504) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error creating assembly archive bin: Failed to retrieve numeric file > attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:189) > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:445) > ... 21 more > Caused by: org.codehaus
[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-tabpanel&focusedCommentId=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
>
> maven-surefire-plugin
> 2.12.2
>
>
> unit-tests
>
> test
>
>
>
> com.mycompany.mavenproject2.UnitTest
>
> ${project.build.directory}/surefire-reports/unit
>
>
>
>
> comp-tests
>
> test
>
>
>
> com.mycompany.mavenproject2.ComponentTest
>
> ${project.build.directory}/surefire-reports/comp
>
>
>
>
> sys-tests
>
> test
>
>
>
> com.mycompany.mavenproject2.SystemTest
>
> ${project.build.directory}/surefire-reports/sys
>
>
>
>
>
>
> 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
> ---
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> Running com.mycompany.mavenproject2.AppTest
> SystemTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> Resul
[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-tabpanel&focusedCommentId=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] (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] (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:
>
>
> install-jrf
>
> zip
>
> false
> ${project.artifactId}
> false
>
>
>
> src/main/resources
> true
>
>
>
> 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] (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-tabpanel&focusedCommentId=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:
>
>
> 1528
> 1528
>
> FileSet config in assembly descriptor:
>
> ${project.build.directory}
>
> ./
>
> /
> 2770
>
> Actual directory mode: drwxrwx---
> If I do not specify 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 or
> 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-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-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-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-tabpanel&focusedCommentId=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-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-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-588) Build fails because of 'ls -1nlaR /'
[ https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > 2>&1 | tee log': > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2:37.924s > [INFO] Finished at: Tue Dec 06 20:30:47 CET 2011 > [INFO] Final Memory: 8M/216M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error creating assembly archive bin: Failed to retrieve numeric > file attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:504) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error creating assembly archive bin: Failed to retrieve numeric file > attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:189) > at > org.apache.maven.plugin.assembly.mojos.Abstract
[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] (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
org.apache.maven.lifecycle.internal.MojoExecutor.ex
[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] (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-tabpanel&focusedCommentId=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 ] 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=1568368&r2=1568367&pathrev=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] (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-tabpanel&focusedCommentId=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=1568368&r2=1568367&pathrev=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] (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-tabpanel&focusedCommentId=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] (MASSEMBLY-588) Build fails because of 'ls -1nlaR /'
[ https://jira.codehaus.org/browse/MASSEMBLY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > 2>&1 | tee log': > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2:37.924s > [INFO] Finished at: Tue Dec 06 20:30:47 CET 2011 > [INFO] Final Memory: 8M/216M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error creating assembly archive bin: Failed to retrieve numeric > file attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:504) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error creating assembly archive bin: Failed to retrieve numeric file > attributes using: '/bin/sh -c ls -1nlaR /' > at
[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 > 2>&1 | tee log': > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2:37.924s > [INFO] Finished at: Tue Dec 06 20:30:47 CET 2011 > [INFO] Final Memory: 8M/216M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-assembly-plugin:2.2.2:single > (package-assembly) on project ebml-viewer: Failed to create assembly: Error > creating assembly archive bin: Failed to retrieve numeric file attributes > using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create > assembly: Error creating assembly archive bin: Failed to retrieve numeric > file attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:504) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: > Error creating assembly archive bin: Failed to retrieve numeric file > attributes using: '/bin/sh -c ls -1nlaR /' > at > org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:189) > at > org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:445) > ... 21 more > Caused by: org.codehaus.plexus.archiver.ArchiverException: Failed to re
[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-tabpanel&focusedCommentId=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}
copy-resources
generate-resources
copy-resources
WhatEver
${basedir}/target/extra-resources
src/non-packaged-resources
true
{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:
> src/main/resourcestrue
> 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] (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
[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}
>
> org.apache.maven.plugins
> maven-resources-plugin
> 2.4.3
>
>
> <%= * %>
>
>UTF-8
>
>
> {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}
> <%=*%>
> <%=*%>
> <%=*%>
>
> {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 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}
>
> org.apache.maven.plugins
> maven-resources-plugin
> 2.4.3
>
>
> <%= * %>
>
>UTF-8
>
>
> {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}
> <%=*%>
> <%=*%>
> <%=*%>
>
> {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] (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-tabpanel&focusedCommentId=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}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {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 {{ 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] (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] (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-tabpanel&focusedCommentId=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] (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-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.
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
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] (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-tabpanel&focusedCommentId=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:
> a>mvn 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] (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-tabpanel&focusedCommentId=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] (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] (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] (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-tabpanel&focusedCommentId=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] (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] (MNG-5699) error running maven project: classpath too long
[ https://jira.codehaus.org/browse/MNG-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] (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-tabpanel&focusedCommentId=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)
