[jira] (MSHARED-325) maven-filtering 1.2 throws MavenFilteringException: Mark invalid
[
https://jira.codehaus.org/browse/MSHARED-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354385#comment-354385
]
Anthony Whitford commented on MSHARED-325:
--
Escaping doesn't solve my problem because I need to filter a build derivative
of which I have limited control over its composition... As a result, it would
be great to see this issue part of the Road Map. :)
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid
>
>
> Key: MSHARED-325
> URL: https://jira.codehaus.org/browse/MSHARED-325
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.2
>Reporter: Mikolaj Izdebski
> Attachments: 0001-Add-unit-test-for-MSHARED-325.patch,
> MSHARED-325-tests.patch, payload
>
>
> maven-filtering 1.2 throws MavenFilteringException: Mark invalid on some
> resource files, which filtering is successfull with version 1.1.
> An example payload is attached. I will attach a reproducer as a unit test
> too.
> {code}
> 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:301)
> ... 21 more
> Caused by: java.io.IOException: Mark invalid
> at java.io.BufferedReader.reset(BufferedReader.java:505)
> 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:140)
> 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)
> ... 23 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-745) -Dtest supports multiple test classes but not multiple test methods
[ https://jira.codehaus.org/browse/SUREFIRE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354383#comment-354383 ] Jianfeng Sun commented on SUREFIRE-745: --- I did try multiple methods from different classes on Maven 3.x, Surefire Failsafe 2.17 with TestNG 6.8.x. But it was still not working by now. According to SureFire website http://maven.apache.org/surefire/maven-failsafe-plugin/examples/single-test.html, it looks like multiple method will only be supported with JUnit 4.x. Will some one add a patch for TestNG? > -Dtest supports multiple test classes but not multiple test methods > --- > > Key: SUREFIRE-745 > URL: https://jira.codehaus.org/browse/SUREFIRE-745 > Project: Maven Surefire > Issue Type: Improvement > Environment: Apache Maven 3.0.2 (r1056850; 2011-01-08 19:58:10-0500) > Java version: 1.6.0_24, vendor: Apple Inc. > Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > Default locale: en_CA, platform encoding: MacRoman > OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac" >Reporter: reid holmes >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.12.1 > > Attachments: multipleMethods.patch, multipleMethods-v2.patch, > multipleMethods-v3.patch, multipleMethods-v4.patch, SUREFIRE-745.patch, > SUREFIRE-745-v2.patch > > > The -Dtest parameter is very handy for running a specific test class or test > method. It also supports running multiple test classes. Unfortunately, it > does not permit specifying running multiple test methods. It would be great > if this were possible. > The examples below are from the Apache Commons project. > WORKS: Run multiple test classes: > mvn test -Dtest=ImmutablePairTest,StopWatchTest > WORKS: Run a specific test method: > mvn test -Dtest=ImmutablePairTest#testBasic > DOES NOT WORK: > mvn test > -Dtest=StopWatchTest#testStopWatchSimple,StopWatchTest#testStopWatchSimpleGet > mvn test -Dtest=ImmutablePairTest#testBasic,StopWatchTest#testLang315 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-731) footer elements in site.xml are ignored
Benson Margulies created MSITE-731: -- Summary: footer elements in site.xml are ignored Key: MSITE-731 URL: https://jira.codehaus.org/browse/MSITE-731 Project: Maven Site Plugin Issue Type: Bug Affects Versions: 3.4 Reporter: Benson Margulies See https://github.com/basis-technology-corp/tcl-regex-java. If you clone this and run mvn site:site, you will see a copyright notice that I don't want, instead of the footer that is supplied in the site.xml. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-352) Update version of plexus-utils to 3.0.18
[ https://jira.codehaus.org/browse/MSHARED-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-352: --- Description: Upgrade plexus-utils to 3.0.15 , .18 in r1631837 Please note that p-u is without function in this project, and the only reason to upgrade is to avoid downloading yet another version was:Upgrade plexus-utils to 3.0.15 Summary: Update version of plexus-utils to 3.0.18 (was: Update version of plexus-utils to 3.0.15) > Update version of plexus-utils to 3.0.18 > > > Key: MSHARED-352 > URL: https://jira.codehaus.org/browse/MSHARED-352 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-1.3 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: maven-filtering-1.3 > > > Upgrade plexus-utils to 3.0.15 , .18 in r1631837 > Please note that p-u is without function in this project, and the only reason > to upgrade is to avoid downloading yet another version -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-366) Add ability to do Stream/Reader based filtering
[ https://jira.codehaus.org/browse/MSHARED-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MSHARED-366. -- Resolution: Fixed Fix Version/s: maven-filtering-1.3 Assignee: Kristian Rosenvold Fixed in r1631834 > Add ability to do Stream/Reader based filtering > --- > > Key: MSHARED-366 > URL: https://jira.codehaus.org/browse/MSHARED-366 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: maven-filtering-1.3 > > > The current API is very file based, meaning files are supposed to be copied > from someplace A to B while applying filtering. This excludes in-places > filter chains and is bad for performance -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-681) plugin ignores empty finalName and uses default value
[
https://jira.codehaus.org/browse/MASSEMBLY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MASSEMBLY-681:
--
Fix Version/s: (was: 2.5)
3.0
> plugin ignores empty finalName and uses default value
> -
>
> Key: MASSEMBLY-681
> URL: https://jira.codehaus.org/browse/MASSEMBLY-681
> Project: Maven Assembly Plugin
> Issue Type: Wish
>Affects Versions: 2.4
>Reporter: Paul Millar
>Assignee: Karl-Heinz Marbaise
>Priority: Minor
> Fix For: 3.0
>
>
> When used in the 'dir' format, I would argue that an empty finalName is
> reasonable.
> For example, I would expect the following configuration, with the 'dir'
> format, to output the assembled files in ${foo.baseDirectory}
>
>
> src/main/assembly/foo.xml
>
> ${foo.baseDirectory}
>
>
> The actual behaviour is to silently ignore the configured empty finalName and
> use the default finalName value, which is append this to the outputDirectory.
> Arguably there are two bugs here:
> finalName is silently ignored (if this is invalid, it should report an
> error)
> the empty finalName is not honoured.
> Specify '.' as the finalName (.) seems to work as a
> work-around, at least for unix-like systems.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MASSEMBLY-673.
-
Resolution: Fixed
Change the implementation cause useDefaultDelimiters can be avoided, cause if
delimiters are given than no defaultDelimiters are needed.
Fixed in [r1631833|http://svn.apache.org/r1631833]
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.5
>
> Attachments: MASSEMBLY-673-patch.txt, MASSEMBLY-673.zip
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-704) Remove all goals which are marked deprecated
[ https://jira.codehaus.org/browse/MASSEMBLY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MASSEMBLY-704: -- Fix Version/s: (was: 2.5) > Remove all goals which are marked deprecated > > > Key: MASSEMBLY-704 > URL: https://jira.codehaus.org/browse/MASSEMBLY-704 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.4.1 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise > > All goals which are marked deprecated should be removed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MASSEMBLY-673:
--
Comment: was deleted
(was: Change the implementation cause useDefaultDelimiters can be avoided,
cause if delimiters are given that no defaultDelimiters are needed.
Fixed in [r1631833|http://svn.apache.org/r1631833])
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.5
>
> Attachments: MASSEMBLY-673-patch.txt, MASSEMBLY-673.zip
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354377#comment-354377
]
Karl-Heinz Marbaise commented on MASSEMBLY-673:
---
Change the implementation cause useDefaultDelimiters can be avoided, cause if
delimiters are given that no defaultDelimiters are needed.
Fixed in [r1631833|http://svn.apache.org/r1631833]
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.5
>
> Attachments: MASSEMBLY-673-patch.txt, MASSEMBLY-673.zip
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354191#comment-354191
]
Karl-Heinz Marbaise edited comment on MASSEMBLY-673 at 10/14/14 1:44 PM:
-
Patch applied in [r1630908|http://svn.apache.org/r1630908].
was (Author: khmarbaise):
Patch applied in [r1630908|http://svn.apache.org/r1630908]. I need to create
integration tests for this.
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.5
>
> Attachments: MASSEMBLY-673-patch.txt, MASSEMBLY-673.zip
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-331) IOException: Mark invalid -- With version 2.5
[
https://jira.codehaus.org/browse/MWAR-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MWAR-331:
--
Description:
Upgrading from {{maven-war-plugin}} version 2.4 to 2.5, caused this build
problem:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.5:war (default-war) on project
wam-commons-extjs: Mark invalid -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-war-plugin
:2.5:war (default-war) on project wam-commons-extjs: Mark invalid
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
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:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Mark invalid
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:248)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.copyResources(WarProjectPackagingTask.java:317)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:132)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:83)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:483)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:411)
at
org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:213)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:176)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 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.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:96)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:244)
... 28 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:505)
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:140)
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)
... 30 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors
[jira] (MWAR-331) IOException: Mark invalid -- With version 2.5
Anthony Whitford created MWAR-331:
-
Summary: IOException: Mark invalid -- With version 2.5
Key: MWAR-331
URL: https://jira.codehaus.org/browse/MWAR-331
Project: Maven WAR Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.5
Environment: Windows 7, Java 7 Update 25, Maven 3.2.1
Reporter: Anthony Whitford
Priority: Blocker
Upgrading from {{maven-war-plugin}} version 2.4 to 2.5, caused this build
problem:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.5:war (default-war) on project
wam-commons-extjs: Mark invalid -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-war-plugin
:2.5:war (default-war) on project wam-commons-extjs: Mark invalid
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
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:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Mark invalid
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:248)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.copyResources(WarProjectPackagingTask.java:317)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:132)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:83)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:483)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:411)
at
org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:213)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:176)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 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.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:96)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:244)
... 28 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:505)
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:140)
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
[jira] (MSHARED-366) Add ability to do Stream/Reader based filtering
Kristian Rosenvold created MSHARED-366: -- Summary: Add ability to do Stream/Reader based filtering Key: MSHARED-366 URL: https://jira.codehaus.org/browse/MSHARED-366 Project: Maven Shared Components Issue Type: Improvement Components: maven-filtering Reporter: Kristian Rosenvold The current API is very file based, meaning files are supposed to be copied from someplace A to B while applying filtering. This excludes in-places filter chains and is bad for performance -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-252) Version 2.13 includes non-source files in checks
[ https://jira.codehaus.org/browse/MCHECKSTYLE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Heuer updated MCHECKSTYLE-252: -- Attachment: mcheckstyle-252.tar.gz Test case extracted from code on dishevelled.org. > Version 2.13 includes non-source files in checks > > > Key: MCHECKSTYLE-252 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-252 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.13 >Reporter: Michael Heuer > Attachments: mcheckstyle-252.tar.gz > > > Updating maven-checkstyle-plugin to version 2.13 and running > $ mvn site > now includes non-source files in its checks, e.g. > COPYING > COPYING.LESSER > target/generated-classes/cobertura/cobertura.properties > While it is rather amusing to have checkstyle complain that COPYING (the text > of the GNU General Public License) doesn't include a license header, it seems > that the default source root or one of the other properties new to version > 2.13 does not have an appropriate default value. The target directory should > also be excluded by default. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-252) Version 2.13 includes non-source files in checks
[ https://jira.codehaus.org/browse/MCHECKSTYLE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354372#comment-354372 ] Michael Heuer commented on MCHECKSTYLE-252: --- I first noticed it here https://svn.code.sf.net/p/dishevelled/code/trunk/worm-plot-cytoscape3-app/ with parent pom here https://svn.code.sf.net/p/dishevelled/code/trunk/parent/ I don't imagine it would be too difficult to come up with an empty test case; I'll see if I can do that this afternoon. > Version 2.13 includes non-source files in checks > > > Key: MCHECKSTYLE-252 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-252 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.13 >Reporter: Michael Heuer > > Updating maven-checkstyle-plugin to version 2.13 and running > $ mvn site > now includes non-source files in its checks, e.g. > COPYING > COPYING.LESSER > target/generated-classes/cobertura/cobertura.properties > While it is rather amusing to have checkstyle complain that COPYING (the text > of the GNU General Public License) doesn't include a license header, it seems > that the default source root or one of the other properties new to version > 2.13 does not have an appropriate default value. The target directory should > also be excluded by default. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-252) Version 2.13 includes non-source files in checks
[ https://jira.codehaus.org/browse/MCHECKSTYLE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354371#comment-354371 ] Dennis Lundberg commented on MCHECKSTYLE-252: - Hi Michael, What does your configuration look like? > Version 2.13 includes non-source files in checks > > > Key: MCHECKSTYLE-252 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-252 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.13 >Reporter: Michael Heuer > > Updating maven-checkstyle-plugin to version 2.13 and running > $ mvn site > now includes non-source files in its checks, e.g. > COPYING > COPYING.LESSER > target/generated-classes/cobertura/cobertura.properties > While it is rather amusing to have checkstyle complain that COPYING (the text > of the GNU General Public License) doesn't include a license header, it seems > that the default source root or one of the other properties new to version > 2.13 does not have an appropriate default value. The target directory should > also be excluded by default. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-779) Surefire reports wrong number of failed tests when using JUnit's ErrorCollector rule
[
https://jira.codehaus.org/browse/SUREFIRE-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-779:
-
Assignee: Tibor Digana
> Surefire reports wrong number of failed tests when using JUnit's
> ErrorCollector rule
>
>
> Key: SUREFIRE-779
> URL: https://jira.codehaus.org/browse/SUREFIRE-779
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
>Reporter: Lieven Doclo
>Assignee: Tibor Digana
>
> When running a test that contains an ErrorCollector, test failures are not
> correct when an errorcollector contains failures. For example:
> {noformat}
> public class ExampleTest {
> @Rule
> public ErrorCollector errorCollector = new ErrorCollector();
> @Test
> public void testWithErrorCollector() {
> errorCollector.checkThat(true, is(false));
> errorCollector.checkThat(3, is(4));
> }
> }
> {noformat}
> Surefire will reports 2 tests run (of which all failed). However, when you
> fix the same test so that no checks fail, Surefire will report 1 test run.
> This is incorrect, as this will result in false information in systems like
> Hudson or Sonar, the number of testcase should not fluctuate. Surefire should
> only report 1 test run, as that reflects the actual situation.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-291) Error when copying within reactor for phases earlier than package
[ https://jira.codehaus.org/browse/MDEP-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354361#comment-354361 ] Ian Brandt commented on MDEP-291: - I would agree that this is a duplicate of MDEP-187. > Error when copying within reactor for phases earlier than package > - > > Key: MDEP-291 > URL: https://jira.codehaus.org/browse/MDEP-291 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.1 > Environment: MacOS 10.6.4 (also seen on Windows XP) > Maven 3.0 > Mac Java 1.6 (also seen on SUN JDK 1.6.0_18 on Windows) >Reporter: Anders Hammar > Attachments: issue-parent.zip > > > For a multi-module project where a module executes > dependency:copy-dependencies on another module in the build, this does not > work when building within the reactor (i.e. executing a phase earlier than > package). > This can be recreated with the attached project: > In the aggregating project, execute "mvn prepare-package". -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-230) failOnError doesn't work when set inside an execution
[
https://jira.codehaus.org/browse/MCOMPILER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354357#comment-354357
]
Jonathan Ogilvie commented on MCOMPILER-230:
I understand the lifecycle. I have two compiler passes on purpose. I have an
annotation processor that runs the first time but not the second (see ).
The annotation processor is running when my server code compiles and generating
Retrofit clients from Spring MVC annotations, but I don't want my server code
to depend on Retrofit, so the generated code doesn't compile. The annotation
processor therefore throws an error, even though it works (the code is
generated). The generated code is compiled in another module. But that's all
beside the point, which is that is sometimes not working
correctly.
This can be recreated with the above pom fragment by throwing an exception
inside an annotation processor.
> failOnError doesn't work when set inside an execution
> -
>
> Key: MCOMPILER-230
> URL: https://jira.codehaus.org/browse/MCOMPILER-230
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: Linux Mint 17 Cinnamon
>Reporter: Jonathan Ogilvie
>
> I have the following plugin configuration in my pom:
> {code:xml}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> ${maven-compiler-plugin.version}
>
>
> annotation-processing
> generate-sources
>
> compile
>
>
> only
> false
>
>
>
> compile-without-generated-source
> compile
>
> compile
>
>
>
> ${project.build.dir}/generated-sources/**
> none
>
>
>
>
> ${java.version}
> ${java.version}
> only
>
>
> {code}
> During the first execution, the build still fails on error. If I move
> to the top-level node or define it on
> the command line instead, the value sticks, but then I can't enable
> failOnError for the second execution.
> Of note: it seems like this works if I negate the whole thing and switch the
> place I'm overriding. If I set it false at the top level configuration, and
> true on an execution, I can get the desired behavior.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-201) Exception during parallel execution (
[
https://jira.codehaus.org/browse/MEAR-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354337#comment-354337
]
Kristian Rosenvold commented on MEAR-201:
-
It would appear to me that the zip file being unpacked is corrupt, so the
source of the problem is probably the creation of the zip file, not exactly the
ear plugin. Now we need to find out /why/ the zip file is corrupted, which is
another story :)
The exception message is not really helpful about *which* file is corrupt, so I
added this to at 2.7.1-SNAPSHOT. If you can build this locally and add it to
your EAR plugin, we could probably get a better idea about exactly /what/ is
corrupted ! You should then be able to verify with a regular zip client that
the archive is corrupt
> Exception during parallel execution (
> -
>
> Key: MEAR-201
> URL: https://jira.codehaus.org/browse/MEAR-201
> Project: Maven Ear Plugin
> Issue Type: Bug
> Environment: Maven 3.1.1
> -T 4.0
>Reporter: Karl-Heinz Marbaise
>
> {code}
> 00:15:15.602 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear (default-ear) on project
> xyz-ear: Execution default-ear of goal
> org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear failed: file mode must
> be 3 or 4 characters -> [Help 1]
> 00:15:15.602 org.apache.maven.lifecycle.LifecycleExecutionException: Failed
> to execute goal org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear
> (default-ear) on project xyz-ear: Execution default-ear of goal
> org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear failed: file mode must
> be 3 or 4 characters
> 00:15:15.602 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 00:15:15.602 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 00:15:15.602 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 00:15:15.602 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 00:15:15.602 at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:169)
> 00:15:15.602 at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:165)
> 00:15:15.602 at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
> 00:15:15.602 at java.util.concurrent.FutureTask.run(FutureTask.java:149)
> 00:15:15.602 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:452)
> 00:15:15.602 at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
> 00:15:15.602 at java.util.concurrent.FutureTask.run(FutureTask.java:149)
> 00:15:15.602 at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
> 00:15:15.602 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
> 00:15:15.602 at java.lang.Thread.run(Thread.java:770)
> 00:15:15.602 Caused by: org.apache.maven.plugin.PluginExecutionException:
> Execution default-ear of goal
> org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear failed: file mode must
> be 3 or 4 characters
> 00:15:15.602 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> 00:15:15.602 at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 00:15:15.602 ... 13 more
> 00:15:15.602 Caused by: java.lang.IllegalArgumentException: file mode must
> be 3 or 4 characters
> 00:15:15.602 at
> org.codehaus.plexus.archiver.util.FilePermissionUtils.getFilePermissionFromMode(FilePermissionUtils.java:55)
> 00:15:15.602 at
> org.codehaus.plexus.archiver.util.ArchiveEntryUtils.applyPermissionsWithJvm(ArchiveEntryUtils.java:133)
> 00:15:15.602 at
> org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:61)
> 00:15:15.602 at
> org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:238)
> 00:15:15.602 at
> org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFileIfIncluded(AbstractZipUnArchiver.java:185)
> 00:15:15.602 at
> org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.execute(AbstractZipUnArchiver.java:149)
> 00:15:15.602 at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:120)
> 00:15:15.602 at
> org.apache.maven.plugin.ear.EarMojo.changeManifestClasspath(EarMojo.java:669)
> 00:15:15.602 at org.apache.maven.plugin.ear.EarMojo.execute(EarMojo.java:338)
> 00:15:15.602 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 00:15:15.602 ... 14 more
> 00:15:15.603 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.9.1:
[jira] (MEAR-201) Exception during parallel execution (
Karl-Heinz Marbaise created MEAR-201:
Summary: Exception during parallel execution (
Key: MEAR-201
URL: https://jira.codehaus.org/browse/MEAR-201
Project: Maven Ear Plugin
Issue Type: Bug
Environment: Maven 3.1.1
-T 4.0
Reporter: Karl-Heinz Marbaise
{code}
00:15:15.602 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear (default-ear) on project
xyz-ear: Execution default-ear of goal
org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear failed: file mode must be
3 or 4 characters -> [Help 1]
00:15:15.602 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear (default-ear)
on project xyz-ear: Execution default-ear of goal
org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear failed: file mode must be
3 or 4 characters
00:15:15.602at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
00:15:15.602at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
00:15:15.602at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
00:15:15.602at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
00:15:15.602at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:169)
00:15:15.602at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:165)
00:15:15.602at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
00:15:15.602at java.util.concurrent.FutureTask.run(FutureTask.java:149)
00:15:15.602at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:452)
00:15:15.602at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
00:15:15.602at java.util.concurrent.FutureTask.run(FutureTask.java:149)
00:15:15.602at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
00:15:15.602at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
00:15:15.602at java.lang.Thread.run(Thread.java:770)
00:15:15.602 Caused by: org.apache.maven.plugin.PluginExecutionException:
Execution default-ear of goal
org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear failed: file mode must be
3 or 4 characters
00:15:15.602at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
00:15:15.602at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
00:15:15.602... 13 more
00:15:15.602 Caused by: java.lang.IllegalArgumentException: file mode must be
3 or 4 characters
00:15:15.602at
org.codehaus.plexus.archiver.util.FilePermissionUtils.getFilePermissionFromMode(FilePermissionUtils.java:55)
00:15:15.602at
org.codehaus.plexus.archiver.util.ArchiveEntryUtils.applyPermissionsWithJvm(ArchiveEntryUtils.java:133)
00:15:15.602at
org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:61)
00:15:15.602at
org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:238)
00:15:15.602at
org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFileIfIncluded(AbstractZipUnArchiver.java:185)
00:15:15.602at
org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.execute(AbstractZipUnArchiver.java:149)
00:15:15.602at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:120)
00:15:15.602at
org.apache.maven.plugin.ear.EarMojo.changeManifestClasspath(EarMojo.java:669)
00:15:15.602at org.apache.maven.plugin.ear.EarMojo.execute(EarMojo.java:338)
00:15:15.602at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
00:15:15.602... 14 more
00:15:15.603 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear (default-ear) on project
abc-ear: Execution default-ear of goal
org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear failed: file mode must be
3 or 4 characters -> [Help 1]
00:15:15.603 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear (default-ear)
on project abc-ear: Execution default-ear of goal
org.apache.maven.plugins:maven-ear-plugin:2.9.1:ear failed: file mode must be
3 or 4 characters
00:15:15.603at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
00:15:15.603at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
00:15:15.603at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
00:15:15.603at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Lif
[jira] (MJAVADOC-404) Goal resource-bundle generates faulty jar file
[
https://jira.codehaus.org/browse/MJAVADOC-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354333#comment-354333
]
Holger Mense commented on MJAVADOC-404:
---
Attached patch against HEAD to fix this issue.
> Goal resource-bundle generates faulty jar file
> --
>
> Key: MJAVADOC-404
> URL: https://jira.codehaus.org/browse/MJAVADOC-404
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Maven 3.0.4, Windows 7
>Reporter: Holger Mense
> Attachments: resource-bundle-showcase.zip,
> ResourcesBundlesMojo.java.patch
>
>
> Hi,
> I am generating a javadoc-resources jar using resource-bundle goal. My
> project has
> additional JavaDoc resources in directory {{src/main/javadoc}} which contains
> several
> subdirectories. So the file structure is as follows:
> {noformat}
> src/main/javadoc/foo
> src/main/javadoc/bar
> {noformat}
> The generated javadoc-resources jar then contains the following structure:
> {noformat}
> META-INF/
> resources/
> resourcesfoo/
> resourcesbar/
> {noformat}
> There seems to be a directory separator missing when generating the
> destination directory structure.
> See attached showcase as example. Generated result is already included in
> {{target/ directory}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-404) Goal resource-bundle generates faulty jar file
[
https://jira.codehaus.org/browse/MJAVADOC-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Holger Mense updated MJAVADOC-404:
--
Attachment: ResourcesBundlesMojo.java.patch
> Goal resource-bundle generates faulty jar file
> --
>
> Key: MJAVADOC-404
> URL: https://jira.codehaus.org/browse/MJAVADOC-404
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Maven 3.0.4, Windows 7
>Reporter: Holger Mense
> Attachments: resource-bundle-showcase.zip,
> ResourcesBundlesMojo.java.patch
>
>
> Hi,
> I am generating a javadoc-resources jar using resource-bundle goal. My
> project has
> additional JavaDoc resources in directory {{src/main/javadoc}} which contains
> several
> subdirectories. So the file structure is as follows:
> {noformat}
> src/main/javadoc/foo
> src/main/javadoc/bar
> {noformat}
> The generated javadoc-resources jar then contains the following structure:
> {noformat}
> META-INF/
> resources/
> resourcesfoo/
> resourcesbar/
> {noformat}
> There seems to be a directory separator missing when generating the
> destination directory structure.
> See attached showcase as example. Generated result is already included in
> {{target/ directory}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MANTRUN-192) filterArtifacts in DependencyFilesetsTask includes entire maven.local.repository
Steve Maring created MANTRUN-192: Summary: filterArtifacts in DependencyFilesetsTask includes entire maven.local.repository Key: MANTRUN-192 URL: https://jira.codehaus.org/browse/MANTRUN-192 Project: Maven Antrun Plugin Issue Type: Bug Affects Versions: 1.7 Reporter: Steve Maring When I define a scope and type, if the dependencyfileset task fails to match anything in my dependencies, the maven.project.dependencies refid will end up containing EVERY artifact found in my local maven repo. A HUGE list. If nothing matches, then maven.project.dependencies should contain nothing. This is what I was trying to do ... merge the contents of map files IF they are found. It is possible that none exist, so my test case was to comment them out, but I end up with a process that is trying to concat EVERY single file in my local Maven repo. org.apache.maven.plugins maven-antrun-plugin 1.7 false merge-maps package run -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-365) Test failures related to symlinks
[
https://jira.codehaus.org/browse/MSHARED-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MSHARED-365.
--
Resolution: Fixed
Assignee: Kristian Rosenvold
Disabled tests until we can release with assembly-2.5, which will support
symlinks
> Test failures related to symlinks
> -
>
> Key: MSHARED-365
> URL: https://jira.codehaus.org/browse/MSHARED-365
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-0.7
> Environment: GNU/Linux
>Reporter: Mikolaj Izdebski
>Assignee: Kristian Rosenvold
>
> There are test failures for symlink-related test cases when building from
> source-release zip. The reason is that
> {{maven-shared-utils-0.7-source-release.zip}} does not contain symbolic
> links, but tests depend on symbolic links being present in sources. There are
> no test failures when building from svn.
> After unpacking source-release zip,
> {{src/test/resources/symlinks/src/symDir}} is a directory, not symlink, so
> {{FileUtilsTest.isASymbolicLink}} obviously fails.
> {{DirectoryScannerTest.followSymlinksFalse}} test fails for simillar reason.
> I recommend creating symlinks during test execution and not packaging them in
> source zip.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
