[jira] [Commented] (MPOM-103) upgrade maven-site-plugin to 3.5.1
[ https://issues.apache.org/jira/browse/MPOM-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229796#comment-15229796 ] Hudson commented on MPOM-103: - SUCCESS: Integrated in ASF Parent Pom #132 (See [https://builds.apache.org/job/ASF%20Parent%20Pom/132/]) [MPOM-103] updated doxia-sitetools to 1.7.1 to test before maven-site-plugin 3.5.1 is released (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1738094]) * pom.xml > upgrade maven-site-plugin to 3.5.1 > -- > > Key: MPOM-103 > URL: https://issues.apache.org/jira/browse/MPOM-103 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-17 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: ASF-18 > > > this will remove MPOM-69 temporary fix -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-769) Can't use property in breadcrumbs items in child module site descriptor
[
https://issues.apache.org/jira/browse/MSITE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229790#comment-15229790
]
Hudson commented on MSITE-769:
--
SUCCESS: Integrated in maven-plugins #5590 (See
[https://builds.apache.org/job/maven-plugins/5590/])
[MSITE-769] doxia-sitetools 1.7.1 is released, with its early interpolation
${this.*} feature (hboutemy:
[http://svn.apache.org/viewvc/?view=rev&rev=1738093])
* maven-site-plugin/pom.xml
> Can't use property in breadcrumbs items in child module site descriptor
> ---
>
> Key: MSITE-769
> URL: https://issues.apache.org/jira/browse/MSITE-769
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: inheritance, site descriptor
>Affects Versions: 3.5
>Reporter: Tony Chemit
>Assignee: Hervé Boutemy
>Priority: Critical
> Fix For: 3.5.1
>
> Attachments: MSITE-769.zip
>
>
> In a multi-module project, I have this in pom module site descriptor
> {noformat}
>
>
>href="${project.url}/v/${siteDeployClassifier}/en/index.html"/>
>
> {noformat}
> While running mvn site, the build fail with this error :
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Illegal character in path at
> index 1: ${project.url}/index.html
> at java.net.URI.create(URI.java:852)
> at
> org.apache.maven.doxia.site.decoration.inheritance.URIPathDescriptor.(URIPathDescriptor.java:69)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler$URLContainer.rebaseLink(DefaultDecorationModelInheritanceAssembler.java:453)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseLinkItemPaths(DefaultDecorationModelInheritanceAssembler.java:300)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.mergeLinkItemLists(DefaultDecorationModelInheritanceAssembler.java:326)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleBodyInheritance(DefaultDecorationModelInheritanceAssembler.java:228)
> at
> org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:109)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1171)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:423)
> at
> org.apache.maven.plugins.site.descriptor.AbstractSiteDescriptorMojo.prepareDecorationModel(AbstractSiteDescriptorMojo.java:86)
> at
> org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:279)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:151)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:135)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.net.URISyntaxException: Illegal character in path at index 1:
> ${project.url}/index.html
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
> at java.net.URI$Parser.parse(URI.java:3063)
> at java.net.URI.(URI.java:588)
> at java.net.URI.create(URI.java:850)
> ... 34 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPOM-103) upgrade maven-site-plugin to 3.5.1
[ https://issues.apache.org/jira/browse/MPOM-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPOM-103: --- Summary: upgrade maven-site-plugin to 3.5.1 (was: upgrade maven-site-plugin to 3.5) > upgrade maven-site-plugin to 3.5.1 > -- > > Key: MPOM-103 > URL: https://issues.apache.org/jira/browse/MPOM-103 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-17 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: ASF-18 > > > this will remove MPOM-69 temporary fix -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCOMPILER-265) IllegalAccessError trying to access package-private method through public subclass (for same package) from another package
[
https://issues.apache.org/jira/browse/MCOMPILER-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229776#comment-15229776
]
Andreas Gudian commented on MCOMPILER-265:
--
If I understand the comments on SO correctly, you got the same result from the
maven run and from manually calling javac and java? At least that wouldn't be a
surprise for me, as the default compiler implementation used by the plugin
simply invokes the JVM's default compiler (which is essentially the same thing
javac does).
Anyway, looking at your code snippets, I'd also say it's abug in the JDK. Did
you try a JDK 9ea build, just for the fun of it?
> IllegalAccessError trying to access package-private method through public
> subclass (for same package) from another package
> ---
>
> Key: MCOMPILER-265
> URL: https://issues.apache.org/jira/browse/MCOMPILER-265
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5.1
> Environment: Eclipse Mars 4.5.1
> Maven 3.3.3
> JDK 8u31
>Reporter: A. Di Matteo
>
> The Maven Compiler Plugin is producing an IllegalAccessError for the use case
> below when normal JDK compiler or Eclipse compiler would not.
> Given the following two classes in package com.sample.package1
> {code}
> package com.sample.package1;
> abstract class Foo {
> public String getFoo() {
> return "foo";
> }
> }
> {code}
> and
> {code}
> package com.sample.package1;
> public class Bar extends Foo {
> public String getBar() {
> return "bar";
> }
> }
> {code}
> And the following test main in package com.sample.package2
> {code}
> package com.sample.package2;
> import java.util.stream.Stream;
> import com.sample.package1.Bar;
> public class Main {
> public static void main(String[] args) {
> System.out.println(new Bar().getFoo());
> // "foo"
> Stream.of(new
> Bar()).map(Bar::getFoo).forEach(System.out::println);
> // IllegalAccessError
> }
> }
> {code}
> The following scenarios occur:
> - Compiling and running the main from Eclipse > No Error
> - Compiling from console/Maven and running the main from Eclipse > Error,
> IllegalAccessError
> - Compiling from console/Maven and running the main via exec:java from
> console > Error, IllegalAccessError
> - Compiling from Eclipse and running the main via exec:java from console > No
> Error
> Stack trace:
> {code}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalAccessError: tried to access class
> com.sample.package1.Foo from class com.sample.package2.Main
> at
> com.sample.package2.Main.lambda$MR$main$getFoo$e8593739$1(Main.java:14)
> at com.sample.package2.Main$$Lambda$1/156299.apply(Unknown Source)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.stream.Streams$StreamBuilderImpl.forEachRemaining(Streams.java:419)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at com.sample.package2.Main.main(Main.java:14)
> ... 6 more
> {code}
> Given the following plugin configuration:
> {code}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.5.1
>
> 1.8
> 1.8
>
>
> {code}
> And changing it to the following:
> {code}
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.5.1
>
> 1.8
> 1.8
> eclipse
>
>
>
> org.codehaus.plexus
> plexus-compiler-eclipse
> 2.7
>
>
>
> {code}
> Would fix the issue, showing indeed an important difference between the Maven
> Compiler and the Eclipse Compiler. Which is also a difference between the JDK
> used and the Eclipse Compiler, hence it might be a bug in th
[jira] [Commented] (MCOMPILER-266) generatedSourcesDirectory added to compileSourceRoots
[
https://issues.apache.org/jira/browse/MCOMPILER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229755#comment-15229755
]
Andreas Gudian commented on MCOMPILER-266:
--
Did you try using the latest version (3.5.1)? That fixes the issue for me. If
it doesn't work for you, then please supply a small test-project and I'll look
into it.
Thanks!
> generatedSourcesDirectory added to compileSourceRoots
> -
>
> Key: MCOMPILER-266
> URL: https://issues.apache.org/jira/browse/MCOMPILER-266
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Reporter: Ben Schulz
>Priority: Critical
>
> Source files generated by the annotation processor are fed into the compiler
> as regular sources. On incremental builds this can lead javac to load
> generated sources before they are re-generated. In such a scenario javac will
> throw an exception (see
> [JDK-8067747|https://bugs.openjdk.java.net/browse/JDK-8067747]).
> To fix this bug, the line [{{compileSourceRoots.add( generatedSourcesPath
> );}}|https://github.com/apache/maven-plugins/blob/cb254e434a40b7ff58c936abbb3f823029a0e466/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L574]
> needs to be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-4777) Match property for profile activation against a regex
[
https://issues.apache.org/jira/browse/MNG-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229683#comment-15229683
]
ASF GitHub Bot commented on MNG-4777:
-
GitHub user vjkoskela opened a pull request:
https://github.com/apache/maven/pull/80
[MNG-4777] Match property for profile activation against a regex
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/vjkoskela/maven mng-4777
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven/pull/80.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #80
commit 2f81de5d883c76ff60e60666d1ffafac6a4f3dcb
Author: Ville Koskela
Date: 2016-04-07T04:43:53Z
[MNG-4777] Match property for profile activation against a regex
> Match property for profile activation against a regex
> -
>
> Key: MNG-4777
> URL: https://issues.apache.org/jira/browse/MNG-4777
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 2.0.11
>Reporter: Andreas Ebbert-Karroum
> Attachments: regex-project-property-profile-activator.patch
>
>
> For activating a profile it would be nice, in addition or as a seperate
> feature to MNG-3328, to match a property not against a specific value but
> against a regex. In our case, we need to set some properties for some hudson
> builds. Not only is that setup fragile against job name changes, but also
> doesn't scale for multiple jobs. IMHO adding a regex matcher would be a nice
> feature for multiple purposes.
> Old:
> {code:xml}
>
>
> env.JOB_NAME
>
> xyz-abc-foo/label=robotframework,maven.browser-profile=firefox,maven.env-profile=dev
>
>
> {code}
> New:
> {code:xml}
>
>
> env.JOB_NAME
> xyz-abc-foo/.*
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MENFORCER-226) requireActiveProfile ignores inherited profiles in submoduless
[
https://issues.apache.org/jira/browse/MENFORCER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229054#comment-15229054
]
Don W Wonders edited comment on MENFORCER-226 at 4/6/16 8:40 PM:
-
Hello All,
I ran into this problem today and believe I've identified why the two plugins
report different profile activations.
The active-profiles help plugin goal first it looks for active profiles using
the “m3” approach
http://svn.apache.org/viewvc/maven/plugins/tags/maven-help-plugin-2.2/src/main/java/org/apache/maven/plugins/help/ActiveProfilesMojo.java?view=markup#l170
If thats not possible it then falls back to the "m2" approach
http://svn.apache.org/viewvc/maven/plugins/tags/maven-help-plugin-2.2/src/main/java/org/apache/maven/plugins/help/ActiveProfilesMojo.java?view=markup#l123
The enforcer plugin's requireActiveProfileRule just relies on the "m2" approach
http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.4.1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireActiveProfile.java?view=markup#l144
Not sure if this is a known limitation/issue of the "m2" approach, but the
enforcer rule should be able to be updated to use both like the help plugin.
Also in the meantime this can be worked around by adding the profile to the
child pom with just the and no contents.
was (Author: wondersd):
Hello All,
I ran into this problem today and believe I've identified why the two plugins
report different profile activations.
The active profiles plugin first it looks for active profiles using the “m3”
approach
http://svn.apache.org/viewvc/maven/plugins/tags/maven-help-plugin-2.2/src/main/java/org/apache/maven/plugins/help/ActiveProfilesMojo.java?view=markup#l170
If thats not possible it then falls back to the "m2" approach
http://svn.apache.org/viewvc/maven/plugins/tags/maven-help-plugin-2.2/src/main/java/org/apache/maven/plugins/help/ActiveProfilesMojo.java?view=markup#l123
The enforcer requireActiveProfileRule just relies on the "m2" approach
http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.4.1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireActiveProfile.java?view=markup#l144
Not sure if this is a known limitation/issue of the "m2" approach, but the
enforcer rule should be able to be updated to use both like the help plugin.
Also in the meantime this can be worked around by adding the profile to the
child pom with just the and no contents.
> requireActiveProfile ignores inherited profiles in submoduless
> --
>
> Key: MENFORCER-226
> URL: https://issues.apache.org/jira/browse/MENFORCER-226
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4
> Environment: Maven 3.2.2, JDK 7, Windows 7 64bit
>Reporter: Yago Méndez Vidal
>Priority: Minor
> Attachments: pom.xml, pom.xml
>
>
> When having a POM project with modules, using the {{requireActiveProfile}}
> rule on one of the modules fails to resolve those profiles that are inherited
> from the parent.
> I've attached 2 POMs to reproduce the problem:
> - parent project defines a profile called {{one}} and enforces it to be active
> - submodule does nothing, just inherits both
> When ran with {{-P one}} parameter we get on the submodule (not the parent
> pom, which works fine):
> {{\[WARNING\] Rule 0: org.apache.maven.plugins.enforcer.RequireActiveProfile
> failed with message:}}
> {{Profile "one" is not activated.}}
> If we run {{mvn -P one help:active-profiles}} we can observe that the profile
> is effectively activated on the submodule:
> {{Active Profiles for Project
> 'example:-maven-subproject:jar:0.0.1-SNAPSHOT':}}
> {{The following profiles are active:}}
> {{- default (source: external)}}
> {{- one (source: example:test-maven-project:0.0.1-SNAPSHOT)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MENFORCER-226) requireActiveProfile ignores inherited profiles in submoduless
[
https://issues.apache.org/jira/browse/MENFORCER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229054#comment-15229054
]
Don W Wonders commented on MENFORCER-226:
-
Hello All,
I ran into this problem today and believe I've identified why the two plugins
report different profile activations.
The active profiles plugin first it looks for active profiles using the “m3”
approach
http://svn.apache.org/viewvc/maven/plugins/tags/maven-help-plugin-2.2/src/main/java/org/apache/maven/plugins/help/ActiveProfilesMojo.java?view=markup#l170
If thats not possible it then falls back to the "m2" approach
http://svn.apache.org/viewvc/maven/plugins/tags/maven-help-plugin-2.2/src/main/java/org/apache/maven/plugins/help/ActiveProfilesMojo.java?view=markup#l123
The enforcer requireActiveProfileRule just relies on the "m2" approach
http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.4.1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireActiveProfile.java?view=markup#l144
Not sure if this is a known limitation/issue of the "m2" approach, but the
enforcer rule should be able to be updated to use both like the help plugin.
Also in the meantime this can be worked around by adding the profile to the
child pom with just the and no contents.
> requireActiveProfile ignores inherited profiles in submoduless
> --
>
> Key: MENFORCER-226
> URL: https://issues.apache.org/jira/browse/MENFORCER-226
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4
> Environment: Maven 3.2.2, JDK 7, Windows 7 64bit
>Reporter: Yago Méndez Vidal
>Priority: Minor
> Attachments: pom.xml, pom.xml
>
>
> When having a POM project with modules, using the {{requireActiveProfile}}
> rule on one of the modules fails to resolve those profiles that are inherited
> from the parent.
> I've attached 2 POMs to reproduce the problem:
> - parent project defines a profile called {{one}} and enforces it to be active
> - submodule does nothing, just inherits both
> When ran with {{-P one}} parameter we get on the submodule (not the parent
> pom, which works fine):
> {{\[WARNING\] Rule 0: org.apache.maven.plugins.enforcer.RequireActiveProfile
> failed with message:}}
> {{Profile "one" is not activated.}}
> If we run {{mvn -P one help:active-profiles}} we can observe that the profile
> is effectively activated on the submodule:
> {{Active Profiles for Project
> 'example:-maven-subproject:jar:0.0.1-SNAPSHOT':}}
> {{The following profiles are active:}}
> {{- default (source: external)}}
> {{- one (source: example:test-maven-project:0.0.1-SNAPSHOT)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MASSEMBLY-803) Add file name mapping option when extracting dependencies
[
https://issues.apache.org/jira/browse/MASSEMBLY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Plamen Totev updated MASSEMBLY-803:
---
Description:
Hi,
Currently when using {{dependencySets}} with {{unpack}} set to {{true}}, there
is no way to set the output file names mapping. As plexus-io supports file
names mapping, I think it will be relatively easy to add such option.
Consider the following scenario. You want to distribute tomcat as part of your
product. You could add something like that;
{code:xml}
org.apache.tomcat:tomcat:8.0.33:zip
true
{code}
So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
folder.What if I want to distribute it under {{tomcat}}? There is no way(AFAIK)
to just extract sub folder of the archive. Of course there is {{}}
tag but the matched files will be still under {{apache-tomcat-8.0.33/...}}
The use of {{FileMapper}} for example may strip the root folder (the
{{RegExpFileMapper}} seems like a perfect candidate).
What do you think about such feature?
p.s. Not quite sure where is the proper place to discuss such improvements
requests - here or in the mailing list. So excuse me if this is not the proper
place.
was:
Hi,
Currently when using dependencySets with unpack set to true there is no way to
set the output file names mapping. As plexus-io supports file names mapping I
think it will be relatively easy to add such option.
Consider the following scenario. You want to distribute tomcat as part of your
product. You could add something like that;
{code:xml}
org.apache.tomcat:tomcat:8.0.33:zip
true
{code}
So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
folder. But what if I want to distribute it under tomcat? there is no way to
just extract sub folder of the archive. Of course there is {{}} tag
but the matched files will be still under {{apache-tomcat-8.0.33/...}}
The use of FileMapper for example may strip the root folder (the
RegExpFileMapper seems like a perfect candidate).
What do you think about such feature?
p.s. Not quite sure where is the proper place to discuss such improvements
requests - here or in the mailing list. So excuse me if this is not the proper
place.
> Add file name mapping option when extracting dependencies
> -
>
> Key: MASSEMBLY-803
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-803
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: dependencySet, moduleSet
>Reporter: Plamen Totev
>Priority: Minor
>
> Hi,
> Currently when using {{dependencySets}} with {{unpack}} set to {{true}},
> there is no way to set the output file names mapping. As plexus-io supports
> file names mapping, I think it will be relatively easy to add such option.
> Consider the following scenario. You want to distribute tomcat as part of
> your product. You could add something like that;
> {code:xml}
>
>
>
> org.apache.tomcat:tomcat:8.0.33:zip
>
> true
>
>
> {code}
> So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
> folder.What if I want to distribute it under {{tomcat}}? There is no
> way(AFAIK) to just extract sub folder of the archive. Of course there is
> {{}} tag but the matched files will be still under
> {{apache-tomcat-8.0.33/...}}
> The use of {{FileMapper}} for example may strip the root folder (the
> {{RegExpFileMapper}} seems like a perfect candidate).
> What do you think about such feature?
> p.s. Not quite sure where is the proper place to discuss such improvements
> requests - here or in the mailing list. So excuse me if this is not the
> proper place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MASSEMBLY-803) Add file name mapping option when extracting dependencies
Plamen Totev created MASSEMBLY-803:
--
Summary: Add file name mapping option when extracting dependencies
Key: MASSEMBLY-803
URL: https://issues.apache.org/jira/browse/MASSEMBLY-803
Project: Maven Assembly Plugin
Issue Type: Improvement
Components: dependencySet, moduleSet
Reporter: Plamen Totev
Priority: Minor
Hi,
Currently when using dependencySets with unpack set to true there is no way to
set the output file names mapping. As plexus-io supports file names mapping I
think it will be relatively easy to add such option.
Consider the following scenario. You want to distribute tomcat as part of your
product. You could add something like that;
{code:xml}
org.apache.tomcat:tomcat:8.0.33:zip
true
{code}
So far so good. But the zip archive contains {{apache-tomcat-8.0.33}} as root
folder. But what if I want to distribute it under tomcat? there is no way to
just extract sub folder of the archive. Of course there is {{}} tag
but the matched files will be still under {{apache-tomcat-8.0.33/...}}
The use of FileMapper for example may strip the root folder (the
RegExpFileMapper seems like a perfect candidate).
What do you think about such feature?
p.s. Not quite sure where is the proper place to discuss such improvements
requests - here or in the mailing list. So excuse me if this is not the proper
place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-802) Dependencies version conflict leads to run-time exception when creating archive
[
https://issues.apache.org/jira/browse/MASSEMBLY-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228894#comment-15228894
]
Hudson commented on MASSEMBLY-802:
--
SUCCESS: Integrated in maven-plugins #5589 (See
[https://builds.apache.org/job/maven-plugins/5589/])
[MASSEMBLY-802] Dependencies version conflict leads to run-time exception when
creating archive
o Upgraded plexus-io from 2.6 to 2.7.1 (khmarbaise:
[http://svn.apache.org/viewvc/?view=rev&rev=1738017])
* maven-assembly-plugin/pom.xml
> Dependencies version conflict leads to run-time exception when creating
> archive
> ---
>
> Key: MASSEMBLY-802
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-802
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Plamen Totev
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> MASSEMBLY-801 updates the plexus-archiver from 3.0.3 to 3.1.
> plexus-archiver 3.1 depends on plexus-io version 2.7.1 On other hand
> maven-assembly-plugin depends on plexus-io 2.6 Because of the version
> conflict(2.6 wins) there is run-time exception when you try to create archive.
> {code}
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.components.io.resources.PlexusIoResourceCollection.isConcurrentAccessSupported()Z
> at
> org.codehaus.plexus.archiver.ArchiveEntry.(ArchiveEntry.java:98)
> at
> org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:181)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.asArchiveEntry(AbstractArchiver.java:388)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.asArchiveEntry(AbstractArchiver.java:425)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.access$300(AbstractArchiver.java:64)
> at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:526)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:352)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:328)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:229)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:965)
> at
> org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:445)
> at
> org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiverTest.addDirectory_NoPerms_CallAcceptFilesOnlyOnce(AssemblyProxyArchiverTest.java:175)
> {code}
> The bug is reproducible with the current tests. Updating the plexus-io
> dependency version to 2.7 resolves the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MASSEMBLY-802) Dependencies version conflict leads to run-time exception when creating archive
[
https://issues.apache.org/jira/browse/MASSEMBLY-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MASSEMBLY-802.
-
Resolution: Fixed
Assignee: Karl Heinz Marbaise
Fixed in [r1738017|http://svn.apache.org/r1738017].
Thanks to Plamen Totev for reporting the issue.
> Dependencies version conflict leads to run-time exception when creating
> archive
> ---
>
> Key: MASSEMBLY-802
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-802
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Plamen Totev
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> MASSEMBLY-801 updates the plexus-archiver from 3.0.3 to 3.1.
> plexus-archiver 3.1 depends on plexus-io version 2.7.1 On other hand
> maven-assembly-plugin depends on plexus-io 2.6 Because of the version
> conflict(2.6 wins) there is run-time exception when you try to create archive.
> {code}
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.components.io.resources.PlexusIoResourceCollection.isConcurrentAccessSupported()Z
> at
> org.codehaus.plexus.archiver.ArchiveEntry.(ArchiveEntry.java:98)
> at
> org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:181)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.asArchiveEntry(AbstractArchiver.java:388)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.asArchiveEntry(AbstractArchiver.java:425)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.access$300(AbstractArchiver.java:64)
> at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:526)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:352)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:328)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:229)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:965)
> at
> org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:445)
> at
> org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiverTest.addDirectory_NoPerms_CallAcceptFilesOnlyOnce(AssemblyProxyArchiverTest.java:175)
> {code}
> The bug is reproducible with the current tests. Updating the plexus-io
> dependency version to 2.7 resolves the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MASSEMBLY-802) Dependencies version conflict leads to run-time exception when creating archive
[
https://issues.apache.org/jira/browse/MASSEMBLY-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MASSEMBLY-802:
--
Fix Version/s: 3.0.0
> Dependencies version conflict leads to run-time exception when creating
> archive
> ---
>
> Key: MASSEMBLY-802
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-802
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Plamen Totev
>Priority: Minor
> Fix For: 3.0.0
>
>
> MASSEMBLY-801 updates the plexus-archiver from 3.0.3 to 3.1.
> plexus-archiver 3.1 depends on plexus-io version 2.7.1 On other hand
> maven-assembly-plugin depends on plexus-io 2.6 Because of the version
> conflict(2.6 wins) there is run-time exception when you try to create archive.
> {code}
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.components.io.resources.PlexusIoResourceCollection.isConcurrentAccessSupported()Z
> at
> org.codehaus.plexus.archiver.ArchiveEntry.(ArchiveEntry.java:98)
> at
> org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:181)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.asArchiveEntry(AbstractArchiver.java:388)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.asArchiveEntry(AbstractArchiver.java:425)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.access$300(AbstractArchiver.java:64)
> at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:526)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:352)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:328)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:229)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:965)
> at
> org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:445)
> at
> org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiverTest.addDirectory_NoPerms_CallAcceptFilesOnlyOnce(AssemblyProxyArchiverTest.java:175)
> {code}
> The bug is reproducible with the current tests. Updating the plexus-io
> dependency version to 2.7 resolves the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (MASSEMBLY-801) Upgrade plexus-archiver from 3.0.3 to 3.1
[ https://issues.apache.org/jira/browse/MASSEMBLY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MASSEMBLY-801: -- Comment: was deleted (was: Commenting in a closed issue is not a good idea.. Better open a separate issue for this, cause you are right...) > Upgrade plexus-archiver from 3.0.3 to 3.1 > - > > Key: MASSEMBLY-801 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-801 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MASSEMBLY-801) Upgrade plexus-archiver from 3.0.3 to 3.1
[ https://issues.apache.org/jira/browse/MASSEMBLY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MASSEMBLY-801: -- Comment: was deleted (was: Hi, Sorry for writing here too but I'm not quite sure how visible the comments in github are so here it goes: plexus-archiver 3.1 depends on plexus-io version 2.7.1 On other hand maven-assembly-plugin depends on plexus-io 2.6 Because of the version conflict(2.6 wins) there is run-time exception when you try to create archive.) > Upgrade plexus-archiver from 3.0.3 to 3.1 > - > > Key: MASSEMBLY-801 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-801 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MASSEMBLY-802) Dependencies version conflict leads to run-time exception when creating archive
Plamen Totev created MASSEMBLY-802:
--
Summary: Dependencies version conflict leads to run-time exception
when creating archive
Key: MASSEMBLY-802
URL: https://issues.apache.org/jira/browse/MASSEMBLY-802
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Plamen Totev
Priority: Minor
MASSEMBLY-801 updates the plexus-archiver from 3.0.3 to 3.1. plexus-archiver
3.1 depends on plexus-io version 2.7.1 On other hand maven-assembly-plugin
depends on plexus-io 2.6 Because of the version conflict(2.6 wins) there is
run-time exception when you try to create archive.
{code}
java.lang.NoSuchMethodError:
org.codehaus.plexus.components.io.resources.PlexusIoResourceCollection.isConcurrentAccessSupported()Z
at
org.codehaus.plexus.archiver.ArchiveEntry.(ArchiveEntry.java:98)
at
org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:181)
at
org.codehaus.plexus.archiver.AbstractArchiver.asArchiveEntry(AbstractArchiver.java:388)
at
org.codehaus.plexus.archiver.AbstractArchiver.asArchiveEntry(AbstractArchiver.java:425)
at
org.codehaus.plexus.archiver.AbstractArchiver.access$300(AbstractArchiver.java:64)
at
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:526)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:352)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:328)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:229)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:965)
at
org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:445)
at
org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiverTest.addDirectory_NoPerms_CallAcceptFilesOnlyOnce(AssemblyProxyArchiverTest.java:175)
{code}
The bug is reproducible with the current tests. Updating the plexus-io
dependency version to 2.7 resolves the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-801) Upgrade plexus-archiver from 3.0.3 to 3.1
[ https://issues.apache.org/jira/browse/MASSEMBLY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228788#comment-15228788 ] Karl Heinz Marbaise commented on MASSEMBLY-801: --- Commenting in a closed issue is not a good idea.. Better open a separate issue for this, cause you are right... > Upgrade plexus-archiver from 3.0.3 to 3.1 > - > > Key: MASSEMBLY-801 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-801 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MASSEMBLY-801) Upgrade plexus-archiver from 3.0.3 to 3.1
[ https://issues.apache.org/jira/browse/MASSEMBLY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228769#comment-15228769 ] Plamen Totev edited comment on MASSEMBLY-801 at 4/6/16 6:04 PM: Hi, Sorry for writing here too but I'm not quite sure how visible the comments in github are so here it goes: plexus-archiver 3.1 depends on plexus-io version 2.7.1 On other hand maven-assembly-plugin depends on plexus-io 2.6 Because of the version conflict(2.6 wins) there is run-time exception when you try to create archive. was (Author: plamenttv): Hi, Sorry for writing here too but I not quite sure how visible the comments in github are so here it goes: plexus-archiver 3.1 depends on plexus-io version 2.7.1 On other hand maven-assembly-plugin depends on plexus-io 2.6 Because of the version conflict(2.6 wins) there is run-time exception when you try to create archive. > Upgrade plexus-archiver from 3.0.3 to 3.1 > - > > Key: MASSEMBLY-801 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-801 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-801) Upgrade plexus-archiver from 3.0.3 to 3.1
[ https://issues.apache.org/jira/browse/MASSEMBLY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228769#comment-15228769 ] Plamen Totev commented on MASSEMBLY-801: Hi, Sorry for writing here too but I not quite sure how visible the comments in github are so here it goes: plexus-archiver 3.1 depends on plexus-io version 2.7.1 On other hand maven-assembly-plugin depends on plexus-io 2.6 Because of the version conflict(2.6 wins) there is run-time exception when you try to create archive. > Upgrade plexus-archiver from 3.0.3 to 3.1 > - > > Key: MASSEMBLY-801 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-801 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRESOURCES-215) Not all resources are copied
[
https://issues.apache.org/jira/browse/MRESOURCES-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228753#comment-15228753
]
Karl Heinz Marbaise commented on MRESOURCES-215:
Hi, that would be great...
> Not all resources are copied
>
>
> Key: MRESOURCES-215
> URL: https://issues.apache.org/jira/browse/MRESOURCES-215
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: $ mvn -version
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_73, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_73.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"
>Reporter: Arek Kita
> Attachments: debug-log.txt, result-console.txt
>
>
> It seems that when I define resources to copy in the following way:
> {code:xml}
>
>
>
>
> ${basedir}/src/main/content/jcr_root
>
>**/*.vlt/**
>**/*.vlt
>**/*.DS_Store
>
>
> {code}
> some files for some directories aren't copied (i.e. {{.content.xml}}) files.
> I tried removing {{excludes}} section but it doesn't help.
> The only thing which solves the problem is removal of the above section in
> favour of the plugin configuration:
> {code:xml}
>
> maven-resources-plugin
>
>
> copy-jcr-content
> generate-resources
>
> copy-resources
>
>
>
> ${project.build.directory}/classes
> true
>
>
>
> ${basedir}/src/main/content/jcr_root
>
>
> **/*.vlt/**
>
> **/*.vlt
>
> **/*.DS_Store
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MJAR-212) AIOOB in AbstractZipArchiver on Java9 EA (jigsaw)
[
https://issues.apache.org/jira/browse/MJAR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved MJAR-212.
--
Resolution: Invalid
Sorry, this has been fixed here:
https://github.com/codehaus-plexus/plexus-archiver/commit/c0357c5234fedb958bc2dd93a8397424bdcea7cf
> AIOOB in AbstractZipArchiver on Java9 EA (jigsaw)
> -
>
> Key: MJAR-212
> URL: https://issues.apache.org/jira/browse/MJAR-212
> Project: Maven JAR Plugin
> Issue Type: Bug
>Reporter: Dawid Weiss
>Priority: Blocker
>
> Java9 changed the {{java.version}} property's naming scheme (see
> http://openjdk.java.net/jeps/223). I tried our projects with build
> {{9-ea+112}} and plexus jar archiver fails with an AIIOOB, specifically on
> this line:
> {code}
> private static final boolean isJava7OrLower =
> Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) <= 7;
> {code}
> https://github.com/sonatype/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L116
> The reason seems obvious. The fix would be based on better version number
> parsing (see the JEP).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MJAR-212) AIOOB in AbstractZipArchiver on Java9 EA (jigsaw)
[
https://issues.apache.org/jira/browse/MJAR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228339#comment-15228339
]
Dawid Weiss commented on MJAR-212:
--
It's the assembly plugin, not the jar plugin -- if somebody can move the issue,
it'd be great (can't see this option).
> AIOOB in AbstractZipArchiver on Java9 EA (jigsaw)
> -
>
> Key: MJAR-212
> URL: https://issues.apache.org/jira/browse/MJAR-212
> Project: Maven JAR Plugin
> Issue Type: Bug
>Reporter: Dawid Weiss
>Priority: Blocker
>
> Java9 changed the {{java.version}} property's naming scheme (see
> http://openjdk.java.net/jeps/223). I tried our projects with build
> {{9-ea+112}} and plexus jar archiver fails with an AIIOOB, specifically on
> this line:
> {code}
> private static final boolean isJava7OrLower =
> Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) <= 7;
> {code}
> https://github.com/sonatype/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L116
> The reason seems obvious. The fix would be based on better version number
> parsing (see the JEP).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1240) failsafe documentation on skipping tests by property does not use property
[ https://issues.apache.org/jira/browse/SUREFIRE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1240: --- Fix Version/s: 2.19.2 > failsafe documentation on skipping tests by property does not use property > -- > > Key: SUREFIRE-1240 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1240 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Affects Versions: 2.19.1 >Reporter: Jörg Sesterhenn >Assignee: Tibor Digana > Fix For: 2.19.2 > > > The example in the > [docs|http://maven.apache.org/surefire/maven-failsafe-plugin/examples/skipping-test.html] > for skipping tests by using a property does not use the configured property > in the plugin configuration. > For a correct example see [surefire > docs|https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-test.html]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SUREFIRE-1240) failsafe documentation on skipping tests by property does not use property
[ https://issues.apache.org/jira/browse/SUREFIRE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1240: -- Assignee: Tibor Digana > failsafe documentation on skipping tests by property does not use property > -- > > Key: SUREFIRE-1240 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1240 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Affects Versions: 2.19.1 >Reporter: Jörg Sesterhenn >Assignee: Tibor Digana > Fix For: 2.19.2 > > > The example in the > [docs|http://maven.apache.org/surefire/maven-failsafe-plugin/examples/skipping-test.html] > for skipping tests by using a property does not use the configured property > in the plugin configuration. > For a correct example see [surefire > docs|https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-test.html]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MJAR-212) AIOOB in AbstractZipArchiver on Java9 EA (jigsaw)
Dawid Weiss created MJAR-212:
Summary: AIOOB in AbstractZipArchiver on Java9 EA (jigsaw)
Key: MJAR-212
URL: https://issues.apache.org/jira/browse/MJAR-212
Project: Maven JAR Plugin
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Blocker
Java9 changed the {{java.version}} property's naming scheme (see
http://openjdk.java.net/jeps/223). I tried our projects with build {{9-ea+112}}
and plexus jar archiver fails with an AIIOOB, specifically on this line:
{code}
private static final boolean isJava7OrLower =
Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) <= 7;
{code}
https://github.com/sonatype/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L116
The reason seems obvious. The fix would be based on better version number
parsing (see the JEP).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SUREFIRE-1240) failsafe documentation on skipping tests by property does not use property
Jörg Sesterhenn created SUREFIRE-1240: - Summary: failsafe documentation on skipping tests by property does not use property Key: SUREFIRE-1240 URL: https://issues.apache.org/jira/browse/SUREFIRE-1240 Project: Maven Surefire Issue Type: Bug Components: documentation Affects Versions: 2.19.1 Reporter: Jörg Sesterhenn The example in the [docs|http://maven.apache.org/surefire/maven-failsafe-plugin/examples/skipping-test.html] for skipping tests by using a property does not use the configured property in the plugin configuration. For a correct example see [surefire docs|https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-test.html]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRESOURCES-215) Not all resources are copied
[
https://issues.apache.org/jira/browse/MRESOURCES-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227973#comment-15227973
]
Arek Kita commented on MRESOURCES-215:
--
Thanks [~khmarbaise] for response and sure I'll try to reproduce this today on
simpler example as I cannot export the whole project as is. Then I'll be able
to attach the project.
> Not all resources are copied
>
>
> Key: MRESOURCES-215
> URL: https://issues.apache.org/jira/browse/MRESOURCES-215
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: $ mvn -version
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_73, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_73.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"
>Reporter: Arek Kita
> Attachments: debug-log.txt, result-console.txt
>
>
> It seems that when I define resources to copy in the following way:
> {code:xml}
>
>
>
>
> ${basedir}/src/main/content/jcr_root
>
>**/*.vlt/**
>**/*.vlt
>**/*.DS_Store
>
>
> {code}
> some files for some directories aren't copied (i.e. {{.content.xml}}) files.
> I tried removing {{excludes}} section but it doesn't help.
> The only thing which solves the problem is removal of the above section in
> favour of the plugin configuration:
> {code:xml}
>
> maven-resources-plugin
>
>
> copy-jcr-content
> generate-resources
>
> copy-resources
>
>
>
> ${project.build.directory}/classes
> true
>
>
>
> ${basedir}/src/main/content/jcr_root
>
>
> **/*.vlt/**
>
> **/*.vlt
>
> **/*.DS_Store
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
