[jira] [Commented] (MNG-6385) Windows mvn.cmd fail with incorrect command syntax.
[
https://issues.apache.org/jira/browse/MNG-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533079#comment-16533079
]
Gili commented on MNG-6385:
---
[~gavenkoa]
1. netbeans.org is dead. The only valid issue tracker now is at
issues.apache.org as I have referenced.
2. No one has yet to establish whether the bug is with Netbeans or Maven. My
guess is that Maven is at fault because older versions of Maven work fine and
newer versions contain a totally-rewritten mvn.cmd file. It's quite possible
that this new version does not handle spaces correctly.
Can a Maven committer please investigate this issue?
> Windows mvn.cmd fail with incorrect command syntax.
> ---
>
> Key: MNG-6385
> URL: https://issues.apache.org/jira/browse/MNG-6385
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0, 3.5.2, 3.5.3
>Reporter: Eric Barboni
>Priority: Major
>
> Hi, during some test using Apache Netbeans on windows it appears that some
> cli can lead to failure of executing mvn.cmd
> It was working before on 3.3.9 version.
> In the code example (below) if space are removed from path in agentpath
> section it works.
> Otherwise the arguments are cut during evaluation
> and the following syntax incorrect will happen
> if not "-agentpath:\"E:\opensource\space" == "" (
> Best Regards
> {code}
> e:\outils\apache-maven-3.5.3\bin\mvn
> -Dexec.args="-agentpath:\"E:\opensource\space
> netbeans\netbeans\profiler\lib\deployed\jdk16\windows-amd64\profilerinterface.dll\"=\"E:\opensource\space
> netbeans\netbeans\profiler\lib\",5140,10 -XX:+HeapDumpOnOutOfMemoryError
> -XX:HeapDumpPath=C:\Users\barboni\AppData\Local\NetBeans\Cache\dev\mavencachedirs\2080072884\org-netbeans-modules-profiler
> -classpath %classpath com.mycompany.mavenproject23.newClass"
> -Dexec.executable="C:\Program Files\Java\jdk1.8.0_162\bin\java.exe"
> -Dexec.classpathScope=runtime -DskipTests=true
> -Dmaven.ext.class.path="E:\opensource\space
> netbeans\netbeans\java\maven-nblib\netbeans-eventspy.jar"
> -Dfile.encoding=UTF-8 org.codehaus.mojo:exec-maven-plugin:1.5.0:exec
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6130) Loss of profile information in workaround for MNG-4900
[
https://issues.apache.org/jira/browse/MNG-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533056#comment-16533056
]
Boris Brodski commented on MNG-6130:
Hello Michael,
Hello Robert,
I tried to use the version 3.0.1 of the 'maven-javadoc-plugin' and this indeed
looks good at the first glance.
Although I do completely understand, why changing the compat-code is a bad
idea, I would like to bring an argument, why this may be not as bad in this
particular case. (Yes, yes, everybody say that :) )
The nature of the bug is kind of random. It strikes rare, but if it strikes,
the activated profiles get deactivated for a particular small execution part
(evaluation sub-tree), that may or may not break builds. The slightest change
in the build environment, like locally available or not available artifacts,
affects the bug. You can run 'mvn clean install' two times - first time the bug
strikes, second time not.
So here is my point: The builds, that we may break by applying this bugfix, are
builds that should already be breaking on the slightest change in the build
environment. So the chances are big, that those builds were fixed, so that they
run no matter if this bug strikes or not.
I hope, you get my idea :)
Cheers,
Boris Brodski
PS I will try to meet you on IRC tomorrow.
> Loss of profile information in workaround for MNG-4900
> --
>
> Key: MNG-6130
> URL: https://issues.apache.org/jira/browse/MNG-6130
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9, 3.5.0
> Environment: Windows
>Reporter: Boris Brodski
>Priority: Major
> Labels: easyfix, patch
> Fix For: waiting-for-feedback
>
> Attachments: MNG-6130.patch
>
>
> Please, forgive me not providing example project reproducing the bug.
> It's very tricky and hopefully not necessary, since the 1-line fix is
> provided.
> Using profiles together with maven-javadoc-plugin results in the following
> problem:
> - Configuration from active profiles is not considered during dependency
> resolution started problematically from the maven-javadoc-plugin.
> This leads to unpredictable behavior, that is somewhat hard to reproduce.
> Here is the technical inside and the 1-line fix:
> In the DefaultMavenProjectBuilder.toRequest():
> {noformat}
> if ( profileManager != null ) {
>...
> } else {
> ...
> /*
>* MNG-4900: Hack to workaround deficiency of legacy API which makes it
> impossible for plugins to access the
>* global profile manager which is required to build a POM like a CLI
> invocation does. Failure to consider
>* the activated profiles can cause repo declarations to be lost which in
> turn will result in artifact
>* resolution failures, in particular when using the enhanced local repo
> which guards access to local files
>* based on the configured remote repos.
>*/
> request.setActiveProfileIds( req.getActiveProfiles() );
> request.setInactiveProfileIds( req.getInactiveProfiles() );
> }
> {noformat}
> Here we copy active and inactive profile ids, but we don't copy the list of
> all profile ids. Missing line:
> {noformat}
> request.setProfiles( req.getProfiles() );
> {noformat}
> As the result the method DefaultProfileManager.getActiveProfiles() always
> returns an empty list:
> {noformat}
> List activeProfiles = new ArrayList<>( profiles.size() );
> for ( Profile profile : profiles ) {
> ...
> }
> return activeProfiles;
> {noformat}
> "profiles" here is empty, since it wasn't copied together with
> "getActiveProfiles()" and "getInactiveProfiles()"
> Adding the missing line fixes the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6385) Windows mvn.cmd fail with incorrect command syntax.
[
https://issues.apache.org/jira/browse/MNG-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533004#comment-16533004
]
Oleksandr Havenko commented on MNG-6385:
Issue has been already reported here:
[https://netbeans.org/bugzilla/show_bug.cgi?id=271059]
As temporary solution using bundled Maven is recommended...
> Windows mvn.cmd fail with incorrect command syntax.
> ---
>
> Key: MNG-6385
> URL: https://issues.apache.org/jira/browse/MNG-6385
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0, 3.5.2, 3.5.3
>Reporter: Eric Barboni
>Priority: Major
>
> Hi, during some test using Apache Netbeans on windows it appears that some
> cli can lead to failure of executing mvn.cmd
> It was working before on 3.3.9 version.
> In the code example (below) if space are removed from path in agentpath
> section it works.
> Otherwise the arguments are cut during evaluation
> and the following syntax incorrect will happen
> if not "-agentpath:\"E:\opensource\space" == "" (
> Best Regards
> {code}
> e:\outils\apache-maven-3.5.3\bin\mvn
> -Dexec.args="-agentpath:\"E:\opensource\space
> netbeans\netbeans\profiler\lib\deployed\jdk16\windows-amd64\profilerinterface.dll\"=\"E:\opensource\space
> netbeans\netbeans\profiler\lib\",5140,10 -XX:+HeapDumpOnOutOfMemoryError
> -XX:HeapDumpPath=C:\Users\barboni\AppData\Local\NetBeans\Cache\dev\mavencachedirs\2080072884\org-netbeans-modules-profiler
> -classpath %classpath com.mycompany.mavenproject23.newClass"
> -Dexec.executable="C:\Program Files\Java\jdk1.8.0_162\bin\java.exe"
> -Dexec.classpathScope=runtime -DskipTests=true
> -Dmaven.ext.class.path="E:\opensource\space
> netbeans\netbeans\java\maven-nblib\netbeans-eventspy.jar"
> -Dfile.encoding=UTF-8 org.codehaus.mojo:exec-maven-plugin:1.5.0:exec
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNGSITE-337) Fluido skin has ancient Apache address hard-coded
[ https://issues.apache.org/jira/browse/MNGSITE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNGSITE-337: -- Summary: Fluido skin has ancient Apache address hard-coded (was: Fluido skin has ancient APache address hard-coded) > Fluido skin has ancient Apache address hard-coded > - > > Key: MNGSITE-337 > URL: https://issues.apache.org/jira/browse/MNGSITE-337 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Ted Dunning >Priority: Major > > The Maven web site has many references to an old ASF address in LA. The > correct address should be > The Apache Software Foundation > 401 Edgewater Place, Suite 600 > Wakefield, MA 01880 > (if any address actually needs to be mentioned, that is) > I filed MNG-6439 to cover the web site itself. This issue is just relative to > the skin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MPOM-194) upgrade compiler target to 1.7 (instead of 1.6)
[ https://issues.apache.org/jira/browse/MPOM-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MPOM-194. -- Resolution: Fixed > upgrade compiler target to 1.7 (instead of 1.6) > --- > > Key: MPOM-194 > URL: https://issues.apache.org/jira/browse/MPOM-194 > Project: Maven POMs > Issue Type: Wish > Components: asf >Affects Versions: ASF-19 >Reporter: Hervé Boutemy >Priority: Major > Fix For: ASF-20 > > > done as part of MPOM-186 but useful to make this change more visible through > a dedicated Jira issue... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MPOM-194) upgrade compiler target to 1.7 (instead of 1.6)
Hervé Boutemy created MPOM-194: -- Summary: upgrade compiler target to 1.7 (instead of 1.6) Key: MPOM-194 URL: https://issues.apache.org/jira/browse/MPOM-194 Project: Maven POMs Issue Type: Wish Components: asf Affects Versions: ASF-19 Reporter: Hervé Boutemy Fix For: ASF-20 done as part of MPOM-186 but useful to make this change more visible through a dedicated Jira issue... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPOM-134) Add profile to use a different resource bundle for incubator projects
[
https://issues.apache.org/jira/browse/MPOM-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532968#comment-16532968
]
Hervé Boutemy commented on MPOM-134:
still no solution: postponing to ASF-21
> Add profile to use a different resource bundle for incubator projects
> -
>
> Key: MPOM-134
> URL: https://issues.apache.org/jira/browse/MPOM-134
> Project: Maven POMs
> Issue Type: Improvement
>Affects Versions: ASF-18
>Reporter: Christopher Tubbs
>Priority: Major
> Fix For: ASF-21
>
>
> The {{org.apache:apache-jar-resource-bundle:1.4}} resourceBundle currently
> specified in the parent POM does not handle the DISCLAIMER file for incubator
> projects.
> It would be nice if there were an incubation profile, which could be
> activated for incubating projects, to use an incubating resource bundle which
> did handle this DISCLAIMER file.
> This could be done in several ways:
> # An optional second execution of the {{maven-remote-resources-plugin}} could
> run when the profile is activated, which handles a second resource bundle for
> the DISCLAIMER file.
> # The current resourceBundle could be turned into a property, which is
> overridden when the profile is activated, using a resourceBundle which
> handles everything the current one does, plus the DISCLAIMER file.
> # The current {{maven-remote-resources-plugin}} execution could have the
> {{}} element changed to {{ combine.children="append">}}, and the profile could specify an additional
> {{}} to handle the DISCLAIMER file, for the same execution id
> of {{maven-remote-resources-plugin}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPOM-134) Add profile to use a different resource bundle for incubator projects
[
https://issues.apache.org/jira/browse/MPOM-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MPOM-134:
---
Fix Version/s: (was: ASF-20)
ASF-21
> Add profile to use a different resource bundle for incubator projects
> -
>
> Key: MPOM-134
> URL: https://issues.apache.org/jira/browse/MPOM-134
> Project: Maven POMs
> Issue Type: Improvement
>Affects Versions: ASF-18
>Reporter: Christopher Tubbs
>Priority: Major
> Fix For: ASF-21
>
>
> The {{org.apache:apache-jar-resource-bundle:1.4}} resourceBundle currently
> specified in the parent POM does not handle the DISCLAIMER file for incubator
> projects.
> It would be nice if there were an incubation profile, which could be
> activated for incubating projects, to use an incubating resource bundle which
> did handle this DISCLAIMER file.
> This could be done in several ways:
> # An optional second execution of the {{maven-remote-resources-plugin}} could
> run when the profile is activated, which handles a second resource bundle for
> the DISCLAIMER file.
> # The current resourceBundle could be turned into a property, which is
> overridden when the profile is activated, using a resourceBundle which
> handles everything the current one does, plus the DISCLAIMER file.
> # The current {{maven-remote-resources-plugin}} execution could have the
> {{}} element changed to {{ combine.children="append">}}, and the profile could specify an additional
> {{}} to handle the DISCLAIMER file, for the same execution id
> of {{maven-remote-resources-plugin}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPOM-186) Upgrade several plugins to most recent versions for JDK9/10 Support
[ https://issues.apache.org/jira/browse/MPOM-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPOM-186: --- Affects Version/s: (was: ASF-20) ASF-19 > Upgrade several plugins to most recent versions for JDK9/10 Support > --- > > Key: MPOM-186 > URL: https://issues.apache.org/jira/browse/MPOM-186 > Project: Maven POMs > Issue Type: Improvement >Affects Versions: ASF-19 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: ASF-20 > > > * maven-clean-plugin 3.1.0 > * maven-compiler-plugin 3.7.0 > * maven-dependency-plugin 3.1.1 > * maven-invoker-plugin 3.1.0 > * maven-javadoc-plugin 3.0.1 > * maven-resources-plugin 3.1.0 > * maven-scm-publish-plugin 3.0.0 > * maven-war-plugin 3.2.2 > * maven-shade-plugin 3.1.1 > * maven-surefire/failsafe 2.22.0 > * maven-plugin-plugin 3.5.2 > * maven-project-info-reports-plugin 3.0.0 > This would imply to lift the minimum JRE torun Maven to JRE 7. This is > related to plugins which are require minimum JDK 7 instead of JDK 6. > Several projects are already upgrading different plugins to get the running > with JDK9/JDK10 (for example surefire) and others as well. Furthermore > [security related things > |http://maven.apache.org/security-plexus-archiver.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Moved] (MNGSITE-337) Fluido skin has ancient APache address hard-coded
[ https://issues.apache.org/jira/browse/MNGSITE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise moved MNG-6440 to MNGSITE-337: -- Key: MNGSITE-337 (was: MNG-6440) Project: Maven Project Web Site (was: Maven) > Fluido skin has ancient APache address hard-coded > - > > Key: MNGSITE-337 > URL: https://issues.apache.org/jira/browse/MNGSITE-337 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Ted Dunning >Priority: Major > > The Maven web site has many references to an old ASF address in LA. The > correct address should be > The Apache Software Foundation > 401 Edgewater Place, Suite 600 > Wakefield, MA 01880 > (if any address actually needs to be mentioned, that is) > I filed MNG-6439 to cover the web site itself. This issue is just relative to > the skin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNGSITE-337) Fluido skin has ancient APache address hard-coded
[ https://issues.apache.org/jira/browse/MNGSITE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532960#comment-16532960 ] Karl Heinz Marbaise commented on MNGSITE-337: - Can you please show which page you exactly mean? > Fluido skin has ancient APache address hard-coded > - > > Key: MNGSITE-337 > URL: https://issues.apache.org/jira/browse/MNGSITE-337 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Ted Dunning >Priority: Major > > The Maven web site has many references to an old ASF address in LA. The > correct address should be > The Apache Software Foundation > 401 Edgewater Place, Suite 600 > Wakefield, MA 01880 > (if any address actually needs to be mentioned, that is) > I filed MNG-6439 to cover the web site itself. This issue is just relative to > the skin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Moved] (MSKINS-144) Maven web site include ancient and non-functional Apache address
[ https://issues.apache.org/jira/browse/MSKINS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise moved MNG-6439 to MSKINS-144: - Key: MSKINS-144 (was: MNG-6439) Project: Maven Skins (was: Maven) > Maven web site include ancient and non-functional Apache address > > > Key: MSKINS-144 > URL: https://issues.apache.org/jira/browse/MSKINS-144 > Project: Maven Skins > Issue Type: Bug >Reporter: Ted Dunning >Priority: Major > > > The correct address is > The Apache Software Foundation > 401 Edgewater Place, Suite 600 > Wakefield, MA 01880 > The old address can be seen in the footer of this page, for example: > http://maven.apache.org/components/skins-archives/maven-fluido-skin-1.4/mskins-22_default/index.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSKINS-144) Maven web site include ancient and non-functional Apache address
[
https://issues.apache.org/jira/browse/MSKINS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532958#comment-16532958
]
Karl Heinz Marbaise commented on MSKINS-144:
These are old skins which shouldn't be used and they are in
{{/skins-archives/}} which is not what you usually access from
https://maven.apache.org/skins/
> Maven web site include ancient and non-functional Apache address
>
>
> Key: MSKINS-144
> URL: https://issues.apache.org/jira/browse/MSKINS-144
> Project: Maven Skins
> Issue Type: Bug
>Reporter: Ted Dunning
>Priority: Major
>
>
> The correct address is
> The Apache Software Foundation
> 401 Edgewater Place, Suite 600
> Wakefield, MA 01880
> The old address can be seen in the footer of this page, for example:
> http://maven.apache.org/components/skins-archives/maven-fluido-skin-1.4/mskins-22_default/index.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6440) Fluido skin has ancient APache address hard-coded
Ted Dunning created MNG-6440: Summary: Fluido skin has ancient APache address hard-coded Key: MNG-6440 URL: https://issues.apache.org/jira/browse/MNG-6440 Project: Maven Issue Type: Bug Reporter: Ted Dunning The Maven web site has many references to an old ASF address in LA. The correct address should be The Apache Software Foundation 401 Edgewater Place, Suite 600 Wakefield, MA 01880 (if any address actually needs to be mentioned, that is) I filed MNG-6439 to cover the web site itself. This issue is just relative to the skin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJDEPS-3) Can't handle long classpath
[ https://issues.apache.org/jira/browse/MJDEPS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532936#comment-16532936 ] Robert Scholte commented on MJDEPS-3: - I think we should switch to a multirelease jar solution, since I don't expect that the commandline issue will be solved. > Can't handle long classpath > --- > > Key: MJDEPS-3 > URL: https://issues.apache.org/jira/browse/MJDEPS-3 > Project: Maven JDeps Plugin > Issue Type: Bug > Environment: Java version: 1.8.0_131, vendor: Oracle Corporation > Java home: C:\java\jdk8\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Clas Forsberg >Priority: Critical > Attachments: error.txt > > > When running I got this error > Cannot run program "C:\java\jdk8\jre\..\bin\jdeps.exe": CreateProcess > error=206, The filename or extension is too long > Mavan debug log attached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6439) Maven web site include ancient and non-functional Apache address
Ted Dunning created MNG-6439: Summary: Maven web site include ancient and non-functional Apache address Key: MNG-6439 URL: https://issues.apache.org/jira/browse/MNG-6439 Project: Maven Issue Type: Bug Reporter: Ted Dunning The correct address is The Apache Software Foundation 401 Edgewater Place, Suite 600 Wakefield, MA 01880 The old address can be seen in the footer of this page, for example: http://maven.apache.org/components/skins-archives/maven-fluido-skin-1.4/mskins-22_default/index.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6415) Project Artifacts Cache does not retain the order of classpath entries.
[ https://issues.apache.org/jira/browse/MNG-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532827#comment-16532827 ] Michael Osipov commented on MNG-6415: - Because it has not been fixed. > Project Artifacts Cache does not retain the order of classpath entries. > --- > > Key: MNG-6415 > URL: https://issues.apache.org/jira/browse/MNG-6415 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.2 > Environment: Windows 7, JDK8u144 >Reporter: Seckin Onur SELAMET >Priority: Major > Labels: CLASSPATH > Attachments: > [MNG-6415]_Fixes_Project_Artifact_Cache_classpath_order_retaining_issue_.patch > > > Project artifacts cache does not retain the order of classpath entries. > Wrong Object type used in implementation. HashSet can not guarantee the order > of elements. > In runtime ProjectArtifacts passed as LinkedHashSet already which is safe. > > Possible fix is provided in comments section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MASSEMBLY-891) Multi-release JAR files aren't handled correctly
Joachim Sauer created MASSEMBLY-891:
---
Summary: Multi-release JAR files aren't handled correctly
Key: MASSEMBLY-891
URL: https://issues.apache.org/jira/browse/MASSEMBLY-891
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Joachim Sauer
Apparently there's now a thing called a multi-release JAR where a JAR file can
contain multiple copies of the same class, where some are used only on certain
Java versions and up (starting with Java 9): [http://openjdk.java.net/jeps/238]
Sounds like a neat idea. For backwards compatibility all the "old" class files
are where they always used to be and new ones are placed under
META-INF/versions//
log4j-api-2.9.1.jar is such a multi-release jar and works just fine.
However, when building a jar-with-dependencies it seems that the "regular"
class file gets overwritten with the Java 9 version of the class file for some
reason.
Looking at log4j-api-2.9.1:
{{$ unzip -l log4j-api-2.9.1.jar | grep StackLocator.class}}
{{ 6336 2017-09-17 22:52 org/apache/logging/log4j/util/StackLocator.class}}
{{ 7264 2017-09-17 22:52
META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class}}
Looking at the jar-with-dependencies produces by maven-assembly-plugin 3.1.0:
{{unzip -l target/myproject-0.0.1-SNAPSHOT-jar-with-dependencies.jar | grep
StackLocator.class}}
{{ 7264 2017-09-17 22:52 org/apache/logging/log4j/util/StackLocator.class}}
{{ 7264 2017-09-17 22:52
META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class}}
Now obviously the best fix would be to make maven-assembly-plugin fully
Multi-release compatible and even write the correct META-INF/MANIFEST.MF Entry
to make it work, but as an intermediate step even just keeping the original
version as provided and not overwriting it with the Java 9 version would be an
improvement.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] mikehearn commented on issue #10: [MRESOLVER-7] Download dependency POMs in parallel v2
mikehearn commented on issue #10: [MRESOLVER-7] Download dependency POMs in parallel v2 URL: https://github.com/apache/maven-resolver/pull/10#issuecomment-402480226 For what it's worth I've been testing it locally a fair bit and it's been working fine. However I had to fork Maven Resolver and add a few commits on top to get it working as well as I wanted it to: https://github.com/mikehearn/maven-resolver/commits/master Specifically, I had to roll back a change that conflicted with this PR, and then I added this commit: https://github.com/mikehearn/maven-resolver/commit/1e2ed26e5c6b7f439882339deae8ff4effec50ac to avoid creating non-daemon threads. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532759#comment-16532759 ] ASF GitHub Bot commented on MRESOLVER-7: mikehearn commented on issue #10: [MRESOLVER-7] Download dependency POMs in parallel v2 URL: https://github.com/apache/maven-resolver/pull/10#issuecomment-402480226 For what it's worth I've been testing it locally a fair bit and it's been working fine. However I had to fork Maven Resolver and add a few commits on top to get it working as well as I wanted it to: https://github.com/mikehearn/maven-resolver/commits/master Specifically, I had to roll back a change that conflicted with this PR, and then I added this commit: https://github.com/mikehearn/maven-resolver/commit/1e2ed26e5c6b7f439882339deae8ff4effec50ac to avoid creating non-daemon threads. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Download dependency POMs in parallel > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Assignee: Michael Osipov >Priority: Major > Fix For: Maven Artifact Resolver 1.1.2 > > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6415) Project Artifacts Cache does not retain the order of classpath entries.
[ https://issues.apache.org/jira/browse/MNG-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532517#comment-16532517 ] Rene Vrijsen commented on MNG-6415: --- Hi [~rfscholte], will this ticket be picked up? I just saw the maven 3.5.4 release (great!) which did not mention this issue. > Project Artifacts Cache does not retain the order of classpath entries. > --- > > Key: MNG-6415 > URL: https://issues.apache.org/jira/browse/MNG-6415 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.2 > Environment: Windows 7, JDK8u144 >Reporter: Seckin Onur SELAMET >Priority: Major > Labels: CLASSPATH > Attachments: > [MNG-6415]_Fixes_Project_Artifact_Cache_classpath_order_retaining_issue_.patch > > > Project artifacts cache does not retain the order of classpath entries. > Wrong Object type used in implementation. HashSet can not guarantee the order > of elements. > In runtime ProjectArtifacts passed as LinkedHashSet already which is safe. > > Possible fix is provided in comments section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
