[jira] [Commented] (MPDF-8) Create one PDF from a multi module project
[ https://issues.apache.org/jira/browse/MPDF-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16486740#comment-16486740 ] ASF GitHub Bot commented on MPDF-8: --- hboutemy commented on issue #1: [MPDF-8] Create one PDF from a multi module project URL: https://github.com/apache/maven-pdf-plugin/pull/1#issuecomment-391226566 everything should be fine now, I'll review in a few days thank you Anthony 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 > Create one PDF from a multi module project > -- > > Key: MPDF-8 > URL: https://issues.apache.org/jira/browse/MPDF-8 > Project: Maven PDF Plugin > Issue Type: New Feature >Reporter: Lukas Theussl >Priority: Major > Fix For: 1.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] hboutemy commented on issue #1: [MPDF-8] Create one PDF from a multi module project
hboutemy commented on issue #1: [MPDF-8] Create one PDF from a multi module project URL: https://github.com/apache/maven-pdf-plugin/pull/1#issuecomment-391226566 everything should be fine now, I'll review in a few days thank you Anthony 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] [Comment Edited] (MNG-3092) Resolution of version ranges with non-snapshot bounds can resolve to a snapshot version
[
https://issues.apache.org/jira/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16486576#comment-16486576
]
Mohammad Norouzi edited comment on MNG-3092 at 5/23/18 1:45 AM:
We really need this. I also think the range should support a format with which
the version can be resolved with. We are moving away from SNAPSHOT to Semantic
Versioning and we want to include only semver format... so for example, when
the version range is like:
{code:java}
[1.0.0, 2.0.0){code}
We don't want other versions like 1.0.00 or 1.0.01 to be included. 1.0.0 and
1.0.1 are valid. This is causing issues and I am trying to create a patch to
customise maven which I am really hesitated to do.
was (Author: xbmono):
We really need this. I also think the range should support a format with which
the version can be resolved with. We are moving away from SNAPSHOT to Semantic
Versioning and we want to include only semver format... so for example, when
the version range is like:
{code:java}
[1.0.0, 2.0.0){code}
We don't want other versions like 1.0.00 or 1.0.01 to be included. 1.0.0 and
1.0.1 are valid. This is causing issues and I am trying to create a patch to
customise maven which I really hesitate to do so.
> Resolution of version ranges with non-snapshot bounds can resolve to a
> snapshot version
> ---
>
> Key: MNG-3092
> URL: https://issues.apache.org/jira/browse/MNG-3092
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Reporter: Mark Hobson
>Priority: Major
> Fix For: 3.x / Backlog
>
> Attachments: MNG-3092.patch, MNG-3092.patch
>
>
> Contrary to the 2.0 design docs:
> "Resolution of dependency ranges should not resolve to a snapshot
> (development version) unless it is included as an explicit boundary."
> -- from
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
> The following is equates to true:
> VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new
> DefaultArtifactVersion( "1.1-SNAPSHOT" ) )
> The attached patch only allows snapshot versions to be contained in a range
> if they are equal to one of the boundaries. Note that this is a strict
> equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-3092) Resolution of version ranges with non-snapshot bounds can resolve to a snapshot version
[
https://issues.apache.org/jira/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16486576#comment-16486576
]
Mohammad Norouzi commented on MNG-3092:
---
We really need this. I also think the range should support a format with which
the version can be resolved with. We are moving away from SNAPSHOT to Semantic
Versioning and we want to include only semver format... so for example, when
the version range is like:
{code:java}
[1.0.0, 2.0.0){code}
We don't want other versions like 1.0.00 or 1.0.01 to be included. 1.0.0 and
1.0.1 are valid. This is causing issues and I am trying to create a patch to
customise maven which I really hesitate to do so.
> Resolution of version ranges with non-snapshot bounds can resolve to a
> snapshot version
> ---
>
> Key: MNG-3092
> URL: https://issues.apache.org/jira/browse/MNG-3092
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Reporter: Mark Hobson
>Priority: Major
> Fix For: 3.x / Backlog
>
> Attachments: MNG-3092.patch, MNG-3092.patch
>
>
> Contrary to the 2.0 design docs:
> "Resolution of dependency ranges should not resolve to a snapshot
> (development version) unless it is included as an explicit boundary."
> -- from
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
> The following is equates to true:
> VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new
> DefaultArtifactVersion( "1.1-SNAPSHOT" ) )
> The attached patch only allows snapshot versions to be contained in a range
> if they are equal to one of the boundaries. Note that this is a strict
> equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider
Tibor17 commented on a change in pull request #184: Donate current sources from junit-platform-surefire-provider URL: https://github.com/apache/maven-surefire/pull/184#discussion_r190059956 ## File path: maven-surefire-plugin/src/site/apt/featurematrix.apt.vm ## @@ -27,19 +27,19 @@ Feature Matrix Not all features are supported for all test frameworks, and the following table gives a brief overview of support status: -*-+---+---++---+--+ -|| <> ||<>||<>||<>||<>||<> | -*-++--++---+--+ -| groups/category support | N |N | Y |Y | N | -*-++--++---+--+ -| security manager support| Y |N | N |N | N | -*-++--++---+--+ -| runOrder support| Y |Y | Y |? | Y | -*-++--++---+--+ -| run >1 individual test method in a class| N |Y | Y |Y | N | -*-++--++---+--+ -| parallel support| N |N | Y |Y | N | -*-++--++---+--+ +*-+---+---++---+--++ +|| <> ||<>||<>||<>||<>||<> ||<> | +*-++--++---+--++ +| groups/category/tags support| N |N | Y |Y | N | Y | +*-++--++---+--++ +| security manager support| Y |N | N |N | N | N | +*-++--++---+--++ +| runOrder support| Y |Y | Y |? | Y | N | +*-++--++---+--++ +| run >1 individual test method in a class| N |Y | Y |Y | N | ? | +*-++--++---+--++ +| parallel support| N |N | Y |Y | N | N | Review comment: @marcphilipp It's better if we implement PC in surefire. We know what configuration we need. Is there something like `Scheduler` as it was in previous JUnit4? Is there a difference between runner and suite? 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] (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=16484605#comment-16484605 ] Michael Osipov commented on MNG-6415: - bq. With Maven the dependency resolution defines the order We have never documented this to be retained throughout. > 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] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484598#comment-16484598
]
Michael Osipov commented on SCM-885:
So, I squashed your commits, added another commit on top. Have a look at the
ticket branch. If everything is fine, I will squash again and merge.
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
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=16484595#comment-16484595
]
Robert Scholte commented on MNG-6415:
-
With Maven the dependency resolution defines the order, there's no such thing
as wildcards, the order is always predictable. Depending on the way the
application is created it is possible to respect the order. With MNG-6025 that
order changed.
I do understand the claim from Thomas, especially when referring to a directory
instead of explicit jars, if you know that
[File.html#listFiles()|https://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles()]
says
{quote}There is no guarantee that the name strings in the resulting array will
appear in any specific order; they are not, in particular, guaranteed to appear
in alphabetical order.{quote}
Maven is a different story, it should not change the order if applications
relies on that (on purpose and on their own risk). Otherwise we should add an
option to randomize the order of the classpath.
> 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] [Comment Edited] (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=16484574#comment-16484574 ] Michael Osipov edited comment on MNG-6415 at 5/22/18 9:08 PM: -- Java makes not guarantees in which order JARs are loaded, especially when you are using wildcard classpaths. Never rely on the order. If you rely on, you seriously have a linkage error in your application. Can you provide a minimal project depicting your issue? was (Author: michael-o): Java makes not guarantees in which order JARs are loaded, especially when you are using wildcard classpaths. Never rely on the order. If you rely on, you seriously have a linkage error in your application. > 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] [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=16484574#comment-16484574 ] Michael Osipov commented on MNG-6415: - Java makes not guarantees in which order JARs are loaded, especially when you are using wildcard classpaths. Never rely on the order. If you rely on, you seriously have a linkage error in your application. > 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] [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=16484571#comment-16484571 ] Seckin Onur SELAMET commented on MNG-6415: -- I kindly disagree with that statement. Java classloader cares about the order of the entries listed in classpath. So the other applications/tools those are built on top of it or those are helping java community to be more productive must follow the same approach. That statement can be an advice for a developer to avoid this kind of bugs or some design rules violated by artifact providers but it is not a technical rule Java features. > 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] [Commented] (MCOMPILER-323) Support multi-release jars
[ https://issues.apache.org/jira/browse/MCOMPILER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484551#comment-16484551 ] Hudson commented on MCOMPILER-323: -- Build succeeded in Jenkins: Maven TLP » maven-compiler-plugin » MCOMPILER-323 #3 See https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/MCOMPILER-323/3/ > Support multi-release jars > -- > > Key: MCOMPILER-323 > URL: https://issues.apache.org/jira/browse/MCOMPILER-323 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Mike Drob >Assignee: Robert Scholte >Priority: Major > > Java 9 allows for JRE version specific code in the form of "multi-release > jars" > Older JREs will treat them as normal jars, while newer JREs will load the > appropriate specific classes. AFAICT, maven does not currently support this. > Compiler plugin should automatically detect when there are multiple source > levels and set MRJAR=True in the manifest. > Source directories could potentially be src/main/java, src/main/java9, > src/main/java10, etc. These probably need to be configurable as well, or some > deeper discussion about what makes sense and is intuitive for users. -- 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=16484528#comment-16484528 ] Michael Osipov commented on MNG-6415: - I concur and always cite [~markt] "never rely on the class path order, if you do so, your app is broken". There has been several reports with Tomcat for class path ordering of webapps and Mark rejected every single one. > 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] [Commented] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484523#comment-16484523
]
Robert Scholte commented on MCOMPILER-343:
--
I think I know what's happening here. The plexus-java is still in its 0.9-phase
and we've decided that the MainModuleDescriptor must point to the actual file,
not anymore to the directory containing the module descriptor.
Conclusion, you either have to path the compiler-plugin yourself or have to
wait a little bit for the next release. And I cannot give you a date for it,
just the hope it'll be in June.
> Tests fail to compile in modularized project due to wrong module descriptor
> path being passed to plexus-java
>
>
> Key: MCOMPILER-343
> URL: https://issues.apache.org/jira/browse/MCOMPILER-343
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Guy Mahieu
>Priority: Major
>
> When running a maven build on a maven project that has a module-info file and
> that has tests to compile, the build fails with the following message:
> {noformat}Execution default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> {noformat}
> And I see that in the TestCompilerMojo class (line 273), the absolute output
> directory is passed in as the module descriptor, while in the compile of the
> production sources, the full path to the module-info.java file is passed in:
> {code}
> ResolvePathsRequest request =
> ResolvePathsRequest.withStrings( testPath )
> .setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
> {code}
>
> For completeness I should maybe also add that I have changed my dependencies
> for the compiler plugin to be able to use java 10 and depend on multi-release
> jars (like log4j2 2.11):
> {code:xml}
>
>
> org.ow2.asm
> asm
> 6.1.1
>
>
> org.codehaus.plexus
> plexus-java
> 0.9.4
>
>
> {code}
>
> Full stacktrace:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project dcm-nct-tcp-connector: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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:497)
> 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.PluginExecutionException: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> at
>
[jira] [Updated] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-343:
-
Description:
When running a maven build on a maven project that has a module-info file and
that has tests to compile, the build fails with the following message:
{noformat}Execution default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
{noformat}
And I see that in the TestCompilerMojo class (line 273), the absolute output
directory is passed in as the module descriptor, while in the compile of the
production sources, the full path to the module-info.java file is passed in:
{code}
ResolvePathsRequest request =
ResolvePathsRequest.withStrings( testPath )
.setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
{code}
For completeness I should maybe also add that I have changed my dependencies
for the compiler plugin to be able to use java 10 and depend on multi-release
jars (like log4j2 2.11):
{code:xml}
org.ow2.asm
asm
6.1.1
org.codehaus.plexus
plexus-java
0.9.4
{code}
Full stacktrace:
{noformat}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project dcm-nct-tcp-connector: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
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:497)
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.PluginExecutionException: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: java.lang.RuntimeException: java.io.IOException: Invalid path to
module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
at
org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:285)
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:762)
at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:176)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
Caused by: java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
at
org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:87)
at
org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:281)
... 24 more
{noformat}
was:
When running a maven build on a maven project that has a
[jira] [Commented] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484315#comment-16484315
]
Robert Scholte commented on MCOMPILER-343:
--
Can you try {{plexus-java 0.9.8}} (it currently the most recent version)
> Tests fail to compile in modularized project due to wrong module descriptor
> path being passed to plexus-java
>
>
> Key: MCOMPILER-343
> URL: https://issues.apache.org/jira/browse/MCOMPILER-343
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Guy Mahieu
>Priority: Major
>
> When running a maven build on a maven project that has a module-info file and
> that has tests to compile, the build fails with the following message:
> {quote}{{Execution default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to modu}}
> {{le descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
> {quote}
> And I see that in the TestCompilerMojo class (line 273), the absolute output
> directory is passed in as the module descriptor, while in the compile of the
> production sources, the full path to the module-info.java file is passed in:
> ResolvePathsRequest request =
> ResolvePathsRequest.withStrings( testPath )
> .setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
>
> For completeness I should maybe also add that I have changed my dependencies
> for the compiler plugin to be able to use java 10 and depend on multi-release
> jars (like log4j2 2.11):
> {quote}{{}}
> \{{ }}
> \{{ org.ow2.asm}}
> \{{ asm}}
> \{{ 6.1.1 }}
> \{{ }}
> \{{ }}
> \{{ org.codehaus.plexus}}
> \{{ plexus-java}}
> \{{ 0.9.4 }}
> \{{ }}
> {{}}
> {quote}
>
> Full stacktrace:
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project dcm-nct-tcp-connector: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to modu}}
> {{le descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
> \{{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)}}
> \{{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)}}
> \{{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)}}
> \{{ at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)}}
> \{{ at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)}}
> \{{ at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)}}
> \{{ at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)}}
> \{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)}}
> \{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)}}
> \{{ at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)}}
> \{{ at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)}}
> \{{ at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)}}
> \{{ at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)}}
> \{{ 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:497)}}
> \{{ 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.PluginExecutionException: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
> \{{ at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)}}
> \{{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)}}
> \{{ ... 20 more}}
> {{Caused by: java.lang.RuntimeException:
[jira] [Updated] (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:all-tabpanel ] Seckin Onur SELAMET updated MNG-6415: - Description: 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. was: Project artifact cache introduced does not retain the order of classpath entries. Wrong Object type used in implementation. HashSet can not guarantee the order of elements contained. In runtime ProjectArtifacts passed as LinkedHashSet already which is safe. Possible fix is provided in comments section. > 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] [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=16484254#comment-16484254 ] Robert Scholte commented on MNG-6415: - Nice catch. This might explain why packaging one of my springboot apps failed with 3.5.2 and not before. > 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 artifact cache introduced does not retain the order of classpath > entries. > Wrong Object type used in implementation. HashSet can not guarantee the order > of elements contained. > 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)
[GitHub] anthony-beurive commented on issue #1: [MPDF-8] Create one PDF from a multi module project
anthony-beurive commented on issue #1: [MPDF-8] Create one PDF from a multi module project URL: https://github.com/apache/maven-pdf-plugin/pull/1#issuecomment-391040017 I switched to JSONUtil. Its license is Apache's 2004. Does it fit? 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] (MPDF-8) Create one PDF from a multi module project
[ https://issues.apache.org/jira/browse/MPDF-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484160#comment-16484160 ] ASF GitHub Bot commented on MPDF-8: --- anthony-beurive commented on issue #1: [MPDF-8] Create one PDF from a multi module project URL: https://github.com/apache/maven-pdf-plugin/pull/1#issuecomment-391040017 I switched to JSONUtil. Its license is Apache's 2004. Does it fit? 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 > Create one PDF from a multi module project > -- > > Key: MPDF-8 > URL: https://issues.apache.org/jira/browse/MPDF-8 > Project: Maven PDF Plugin > Issue Type: New Feature >Reporter: Lukas Theussl >Priority: Major > Fix For: 1.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (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=16483775#comment-16483775
]
Seckin Onur SELAMET edited comment on MNG-6415 at 5/22/18 1:13 PM:
---
Rev no : be223808939d75152d7157db33d45f230114555e
Class : DefaultProjectArtifactsCache
Line : 208
{color:#ff}_new CacheRecord( Collections.unmodifiableSet( new HashSet<>(
projectArtifacts ) ) );_{color}
Must be implemented as:
new CacheRecord( Collections.unmodifiableSet( new LinkedHashSet<>(
projectArtifacts ) ) );
Patch is also available in attachments.
was (Author: soselamet):
Rev no : be223808939d75152d7157db33d45f230114555e
Line : 208
{color:#FF}_new CacheRecord( Collections.unmodifiableSet( new HashSet<>(
projectArtifacts ) ) );_{color}
Must be implemented as:
new CacheRecord( Collections.unmodifiableSet( new LinkedHashSet<>(
projectArtifacts ) ) );
> 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 artifact cache introduced does not retain the order of classpath
> entries.
> Wrong Object type used in implementation. HashSet can not guarantee the order
> of elements contained.
> 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)
[GitHub] zregvart commented on issue #5: Don't resolve any dependencies
zregvart commented on issue #5: Don't resolve any dependencies URL: https://github.com/apache/maven-checkstyle-plugin/pull/5#issuecomment-390983957 I've created an issue to track this: https://issues.apache.org/jira/browse/MCHECKSTYLE-353 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] [Created] (MCHECKSTYLE-353) Don't resolve any dependencies
Zoran Regvart created MCHECKSTYLE-353: - Summary: Don't resolve any dependencies Key: MCHECKSTYLE-353 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-353 Project: Maven Checkstyle Plugin Issue Type: Improvement Components: checkstyle:check Affects Versions: 3.0.0 Reporter: Zoran Regvart Not sure why resolving dependencies is needed for running Checkstyle, it does slow down the build considerably. For Apache Camel this makes a ten fold difference from ~20mins to ~2mins for running mvn checkstyle:check. Seems this was introduced with MCHECKSTYLE-163 but subsequently integration test was removed in MCHECKSTYLE-272. I've created a GitHub pull request to address this: https://github.com/apache/maven-checkstyle-plugin/pull/5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MDEP-609) Dependency analyzer gets confused if the same package is defined in 2 different artifacts
[
https://issues.apache.org/jira/browse/MDEP-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ahmed Hammad updated MDEP-609:
--
Description:
The issue might be related to MNG-6415
If a certain package is defined in 2 different artifacts, and a a maven module
declares a dependency on these 2 artifacts (once through a transitive
dependency and once using a declared dependency), dependency analyzer reports
the dependency as "Used Undeclared", while declared dependencies should always
take precedence (even if they appear later in the POM)
For example:
Project 1 pom:
{code:java}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
test
project1
1.0.0-SNAPSHOT
test
project2
1.0.0-SNAPSHOT
org.hamcrest
hamcrest-all
1.1
{code}
Project 2 pom:
{code:java}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
test
project2
1.0.0-SNAPSHOT
org.hamcrest
hamcrest-core
1.3
{code}
And Project 1 uses a package which can be found in both hamcrest-core and
hamcrest-all:
{code:java}
import org.hamcrest.core.IsEqual;
class Test {
IsEqual isEqual;
}
{code}
When doing a dependency analysis for Project 1, no "Used undeclared" are
expected to be seen, because Project 1 declares a dependency on hamcrest-all.
However, I get:
[INFO] — maven-dependency-plugin:2.8:analyze (default-cli) @ project1 —
[WARNING] Used undeclared dependencies found:
[WARNING] org.hamcrest:hamcrest-core:jar:1.3:compile
was:
If a certain package is defined in 2 different artifacts, and a a maven module
declares a dependency on these 2 artifacts (once through a transitive
dependency and once using a declared dependency), dependency analyzer reports
the dependency as "Used Undeclared", while declared dependencies should always
take precedence (even if they appear later in the POM)
For example:
Project 1 pom:
{code:java}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
test
project1
1.0.0-SNAPSHOT
test
project2
1.0.0-SNAPSHOT
org.hamcrest
hamcrest-all
1.1
{code}
Project 2 pom:
{code:java}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
test
project2
1.0.0-SNAPSHOT
org.hamcrest
hamcrest-core
1.3
{code}
And Project 1 uses a package which can be found in both hamcrest-core and
hamcrest-all:
{code:java}
import org.hamcrest.core.IsEqual;
class Test {
IsEqual isEqual;
}
{code}
When doing a dependency analysis for Project 1, no "Used undeclared" are
expected to be seen, because Project 1 declares a dependency on hamcrest-all.
However, I get:
[INFO] — maven-dependency-plugin:2.8:analyze (default-cli) @ project1 —
[WARNING] Used undeclared dependencies found:
[WARNING] org.hamcrest:hamcrest-core:jar:1.3:compile
> Dependency analyzer gets confused if the same package is defined in 2
> different artifacts
> -
>
> Key: MDEP-609
> URL: https://issues.apache.org/jira/browse/MDEP-609
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.0
>Reporter: Ahmed Hammad
>Priority: Major
>
> The issue might be related to MNG-6415
> If a certain package is defined in 2 different artifacts, and a a maven
> module declares a dependency on these 2 artifacts (once through a transitive
> dependency and once using a declared dependency), dependency analyzer reports
> the dependency as "Used Undeclared", while declared dependencies should
> always take precedence (even if they appear later in the POM)
> For example:
> Project 1 pom:
> {code:java}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>test
> project1
> 1.0.0-SNAPSHOT
>
>
> test
>
[jira] [Updated] (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:all-tabpanel ] Seckin Onur SELAMET updated MNG-6415: - Attachment: [MNG-6415]_Fixes_Project_Artifact_Cache_classpath_order_retaining_issue_.patch > 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 artifact cache introduced does not retain the order of classpath > entries. > Wrong Object type used in implementation. HashSet can not guarantee the order > of elements contained. > 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] [Updated] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guy Mahieu updated MCOMPILER-343:
-
Description:
When running a maven build on a maven project that has a module-info file and
that has tests to compile, the build fails with the following message:
{quote}{{Execution default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to modu}}
{{le descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
{quote}
And I see that in the TestCompilerMojo class (line 273), the absolute output
directory is passed in as the module descriptor, while in the compile of the
production sources, the full path to the module-info.java file is passed in:
ResolvePathsRequest request =
ResolvePathsRequest.withStrings( testPath )
.setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
For completeness I should maybe also add that I have changed my dependencies
for the compiler plugin to be able to use java 10 and depend on multi-release
jars (like log4j2 2.11):
{quote}{{}}
\{{ }}
\{{ org.ow2.asm}}
\{{ asm}}
\{{ 6.1.1 }}
\{{ }}
\{{ }}
\{{ org.codehaus.plexus}}
\{{ plexus-java}}
\{{ 0.9.4 }}
\{{ }}
{{}}
{quote}
Full stacktrace:
{{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project dcm-nct-tcp-connector: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to modu}}
{{le descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
\{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)}}
\{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)}}
\{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)}}
\{{ at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)}}
\{{ at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)}}
\{{ at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)}}
\{{ at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)}}
\{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)}}
\{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)}}
\{{ at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)}}
\{{ at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)}}
\{{ at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)}}
\{{ at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)}}
\{{ 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:497)}}
\{{ 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.PluginExecutionException: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
\{{ at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)}}
\{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)}}
\{{ ... 20 more}}
{{Caused by: java.lang.RuntimeException: java.io.IOException: Invalid path to
module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
\{{ at
org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:285)}}
\{{ at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:762)}}
\{{ at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:176)}}
\{{ at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)}}
\{{ ... 21 more}}
{{Caused by: java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
\{{ at
[jira] [Updated] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guy Mahieu updated MCOMPILER-343:
-
Description:
When running a maven build on a maven project that has a module-info file and
that has tests to compile, the build fails with the following message:
{quote}{{Execution default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to modu}}
{{le descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
{quote}
And I see that in the TestCompilerMojo class (line 273), the absolute output
directory is passed in as the module descriptor, while in the compile of the
production sources, the full path to the module-info.java file is passed in:
ResolvePathsRequest request =
ResolvePathsRequest.withStrings( testPath )
.setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
For completeness I should maybe also add that I have changed my dependencies
for the compiler plugin to be able to use java 10 and depend on multi-versioned
jars:
{quote}{{}}
\{{ }}
\{{ org.ow2.asm}}
\{{ asm}}
\{{ 6.1.1 }}
\{{ }}
\{{ }}
\{{ org.codehaus.plexus}}
\{{ plexus-java}}
\{{ 0.9.4 }}
\{{ }}
{{}}
{quote}
Full stacktrace:
{{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project dcm-nct-tcp-connector: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to modu}}
{{le descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
\{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)}}
\{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)}}
\{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)}}
\{{ at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)}}
\{{ at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)}}
\{{ at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)}}
\{{ at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)}}
\{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)}}
\{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)}}
\{{ at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)}}
\{{ at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)}}
\{{ at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)}}
\{{ at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)}}
\{{ 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:497)}}
\{{ 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.PluginExecutionException: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
\{{ at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)}}
\{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)}}
\{{ ... 20 more}}
{{Caused by: java.lang.RuntimeException: java.io.IOException: Invalid path to
module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
\{{ at
org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:285)}}
\{{ at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:762)}}
\{{ at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:176)}}
\{{ at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)}}
\{{ ... 21 more}}
{{Caused by: java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
\{{ at
org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:87)}}
[jira] [Created] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
Guy Mahieu created MCOMPILER-343:
Summary: Tests fail to compile in modularized project due to wrong
module descriptor path being passed to plexus-java
Key: MCOMPILER-343
URL: https://issues.apache.org/jira/browse/MCOMPILER-343
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.7.0
Reporter: Guy Mahieu
When running a maven build on a maven project that has a module-info file and
that has tests to compile, the build fails with the following message:
{quote}{{Execution default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to modu}}
{{le descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
{quote}
And I see that in the TestCompilerMojo class (line 273), the absolute output
directory is passed in as the module descriptor, while in the compile of the
production sources, the full path to the module-info.java file is passed in:
Test compile:
ResolvePathsRequest request =
ResolvePathsRequest.withStrings( testPath )
.setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
For completeness I should maybe also add that I have changed my dependencies
for the compiler plugin to be able to use java 10 and depend on multi-versioned
jars:
{quote}{{}}
{{ }}
{{ org.ow2.asm}}
{{ asm}}
{{ 6.1.1 }}
{{ }}
{{ }}
{{ org.codehaus.plexus}}
{{ plexus-java}}
{{ 0.9.4 }}
{{ }}
{{}}
{quote}
Full stacktrace:
{{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project dcm-nct-tcp-connector: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to modu}}
{{le descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)}}
{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)}}
{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)}}
{{ at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)}}
{{ at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)}}
{{ at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)}}
{{ at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)}}
{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)}}
{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)}}
{{ at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)}}
{{ at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)}}
{{ at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)}}
{{ at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)}}
{{ 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:497)}}
{{ 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.PluginExecutionException: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
{{ at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)}}
{{ at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)}}
{{ ... 20 more}}
{{Caused by: java.lang.RuntimeException: java.io.IOException: Invalid path to
module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
{{ at
org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:285)}}
{{ at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:762)}}
{{ at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:176)}}
{{ at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)}}
{{ ... 21 more}}
{{Caused by: java.io.IOException: Invalid path to module descriptor:
[jira] [Updated] (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:all-tabpanel ] Seckin Onur SELAMET updated MNG-6415: - Description: Project artifact cache introduced does not retain the order of classpath entries. Wrong Object type used in implementation. HashSet can not guarantee the order of elements contained. In runtime ProjectArtifacts passed as LinkedHashSet already which is safe. Possible fix is provided in comments section. > 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 > > Project artifact cache introduced does not retain the order of classpath > entries. > Wrong Object type used in implementation. HashSet can not guarantee the order > of elements contained. > 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] [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=16483775#comment-16483775
]
Seckin Onur SELAMET commented on MNG-6415:
--
Rev no : be223808939d75152d7157db33d45f230114555e
Line : 208
{color:#FF}_new CacheRecord( Collections.unmodifiableSet( new HashSet<>(
projectArtifacts ) ) );_{color}
Must be implemented as:
new CacheRecord( Collections.unmodifiableSet( new LinkedHashSet<>(
projectArtifacts ) ) );
> 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
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6415) Project Artifacts Cache does not retain the order of classpath entries.
Seckin Onur SELAMET created MNG-6415: Summary: 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 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483692#comment-16483692
]
ASF GitHub Bot commented on SCM-885:
michael-o commented on issue #74: [SCM-885] third implementation
URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390918449
I am aware of that, but it still remains bloat for the test.
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
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #74: [SCM-885] third implementation
michael-o commented on issue #74: [SCM-885] third implementation URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390918449 I am aware of that, but it still remains bloat for the test. 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] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483676#comment-16483676
]
ASF GitHub Bot commented on SCM-885:
McFoggy commented on issue #74: [SCM-885] third implementation
URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390914512
I'll do a what I can do to cleanup the git internals but honestly what you
call _bloat_ is just the result of a pure `git clone --bare`.
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
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] McFoggy commented on issue #74: [SCM-885] third implementation
McFoggy commented on issue #74: [SCM-885] third implementation URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390914512 I'll do a what I can do to cleanup the git internals but honestly what you call _bloat_ is just the result of a pure `git clone --bare`. 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
[GitHub] michael-o commented on issue #74: [SCM-885] third implementation
michael-o commented on issue #74: [SCM-885] third implementation URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390892686 The code looks way better now, I am fine adding a new repo for a test, but I don't hink we need to commit bloat. See the other test repos, they have a minimal set of files: no hooks or stuff. They aren't necessary. Also have a look at `config` it contains a local path from your computer. Please align and I will run tests, and merge. 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] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483594#comment-16483594
]
ASF GitHub Bot commented on SCM-885:
michael-o commented on issue #74: [SCM-885] third implementation
URL: https://github.com/apache/maven-scm/pull/74#issuecomment-390892686
The code looks way better now, I am fine adding a new repo for a test, but I
don't hink we need to commit bloat. See the other test repos, they have a
minimal set of files: no hooks or stuff. They aren't necessary. Also have a
look at `config` it contains a local path from your computer. Please align and
I will run tests, and merge.
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
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6401) Cannot interpolate property in proxy port of settings.xml
[
https://issues.apache.org/jira/browse/MNG-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483585#comment-16483585
]
ASF GitHub Bot commented on MNG-6401:
-
michael-o commented on issue #163: [MNG-6401] - Cannot interpolate property in
proxy port of settings.xml
URL: https://github.com/apache/maven/pull/163#issuecomment-390888715
@hboutemy , looks good to me. Did you have a chance to run the new IT on?
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
> Cannot interpolate property in proxy port of settings.xml
> -
>
> Key: MNG-6401
> URL: https://issues.apache.org/jira/browse/MNG-6401
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.0, 3.5.3
>Reporter: KATADA Junya
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.6.0-candidate
>
>
> If you use a property in proxy port of settings.xml, the property is not
> replaced and the port number is "0" instead of property value.
> My minimal demo about this problem is
> [here|https://github.com/jkatada/maven-property-demo].
> In my demo, export two environment variables as follows.
> {code}
> export MAVEN_PROXY_HOST_STRING=proxy.foo.com
> export MAVEN_PROXY_PORT_INT=18080
> {code}
> These variables are used in settings.xml for proxy settings.
> {code:xml}
>
> my_proxy
> true
> http
> ${env.MAVEN_PROXY_HOST_STRING}
> ${env.MAVEN_PROXY_PORT_INT}
> local.net|some.host.com
>
> {code}
> Execute maven-help-plugin to show effective settings.xml.
> {code}
> mvn help:effective-settings -X
> {code}
> The result is as follows.
> {code:xml}
>
> 0
> proxy.foo.com
> local.net|some.host.com
> my_proxy
>
> {code}
> `*${env.MAVEN_PROXY_HOST_STRING}*` is replaced with `*proxy.foo.com*`,
> but `*${env.MAVEN_PROXY_PORT_INT}*` is not replaced with `*18080*`.
> I found the following WARNING message in console.
> {code:java}
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unable to parse element 'port', must be an integer (position:
> END_TAG seen ...${env.MAVEN_PROXY_PORT_INT}... @12:47) caused
> by: java.lang.NumberFormatException: For input string:
> "${env.MAVEN_PROXY_PORT_INT}" @ /root/.m2/settings.xml, line 12, column 47
> {code}
> I think that the cause of this problem is to parse settings.xml before
> interpolation.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #163: [MNG-6401] - Cannot interpolate property in proxy port of settings.xml
michael-o commented on issue #163: [MNG-6401] - Cannot interpolate property in proxy port of settings.xml URL: https://github.com/apache/maven/pull/163#issuecomment-390888715 @hboutemy , looks good to me. Did you have a chance to run the new IT on? 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] (SCM-885) GitChangeLogCommand is wrong when only endVersion is set
[
https://issues.apache.org/jira/browse/SCM-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483574#comment-16483574
]
ASF GitHub Bot commented on SCM-885:
michael-o commented on a change in pull request #74: [SCM-885] third
implementation
URL: https://github.com/apache/maven-scm/pull/74#discussion_r189795759
##
File path:
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java
##
@@ -89,17 +97,28 @@ protected ChangeLogScmResult executeChangeLogCommand(
ChangeLogScmRequest reques
final String datePattern = request.getDatePattern();
return executeChangeLogCommand(
request.getScmRepository().getProviderRepository(), fileSet,
request.getStartDate(), request.getEndDate(),
request.getScmBranch(), datePattern, startVersion,
-endVersion, request.getLimit() );
+endVersion, request.getLimit(), request.getRevision() );
Review comment:
Let's leave it as-is right now.
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
> GitChangeLogCommand is wrong when only endVersion is set
>
>
> Key: SCM-885
> URL: https://issues.apache.org/jira/browse/SCM-885
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5
>Reporter: Matthieu Brouillard
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.9.6
>
> Attachments: scm-885-different-behavior-exe-jgit-patch.diff
>
>
> Invoking execution of a GitChangeLogCommand where only the end revision has
> been set produces a wrong out.
> +Actual result:+
> {{git whatchanged --date=iso ..END_REVISION_SHA1 -- PROJECT_PATH}}
> +Expected result:+ only the end revison SHA1 is used without the two dots
> {{git whatchanged --date=iso END_REVISION_SHA1 -- PROJECT_PATH}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on a change in pull request #74: [SCM-885] third implementation
michael-o commented on a change in pull request #74: [SCM-885] third implementation URL: https://github.com/apache/maven-scm/pull/74#discussion_r189795759 ## File path: maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogCommand.java ## @@ -89,17 +97,28 @@ protected ChangeLogScmResult executeChangeLogCommand( ChangeLogScmRequest reques final String datePattern = request.getDatePattern(); return executeChangeLogCommand( request.getScmRepository().getProviderRepository(), fileSet, request.getStartDate(), request.getEndDate(), request.getScmBranch(), datePattern, startVersion, -endVersion, request.getLimit() ); +endVersion, request.getLimit(), request.getRevision() ); Review comment: Let's leave it as-is right now. 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] (MNG-6414) Add more Apache license header patterns to skip downloading Apache license
[ https://issues.apache.org/jira/browse/MNG-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483535#comment-16483535 ] ASF GitHub Bot commented on MNG-6414: - slachiewicz commented on issue #167: MNG-6414 Add more Apache license headers to skip downloading license … URL: https://github.com/apache/maven/pull/167#issuecomment-390873663 The side effect is skip of downloading the license file from www.apache.org what produces error on Java 7 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 > Add more Apache license header patterns to skip downloading Apache license > -- > > Key: MNG-6414 > URL: https://issues.apache.org/jira/browse/MNG-6414 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Minor > > While preparing Maven distribution maven-remote-resources-plugin try to > download licenses for all dependencies. > License file is not downloaded only when project/license/name is equal to > "The Apache Software License, Version 2.0". > Additional patterns exists and needs to be added to exception list in > appended-resources/META-INF/LICENSE.vm: > Apache License, Version 2.0 > The Apache Software License, Version 2.0 > ASLv2 > Apache Public License 2.0 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] slachiewicz commented on issue #167: MNG-6414 Add more Apache license headers to skip downloading license …
slachiewicz commented on issue #167: MNG-6414 Add more Apache license headers to skip downloading license … URL: https://github.com/apache/maven/pull/167#issuecomment-390873663 The side effect is skip of downloading the license file from www.apache.org what produces error on Java 7 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] (MNG-6414) Add more Apache license header patterns to skip downloading Apache license
[ https://issues.apache.org/jira/browse/MNG-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483534#comment-16483534 ] ASF GitHub Bot commented on MNG-6414: - slachiewicz opened a new pull request #167: MNG-6414 Add more Apache license headers to skip downloading license … URL: https://github.com/apache/maven/pull/167 …text To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) 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 > Add more Apache license header patterns to skip downloading Apache license > -- > > Key: MNG-6414 > URL: https://issues.apache.org/jira/browse/MNG-6414 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Minor > > While preparing Maven distribution maven-remote-resources-plugin try to > download licenses for all dependencies. > License file is not downloaded only when project/license/name is equal to > "The Apache Software License, Version 2.0". > Additional patterns exists and needs to be added to exception list in > appended-resources/META-INF/LICENSE.vm: > Apache License, Version 2.0 > The Apache Software License, Version 2.0 > ASLv2 > Apache Public License 2.0 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] slachiewicz opened a new pull request #167: MNG-6414 Add more Apache license headers to skip downloading license …
slachiewicz opened a new pull request #167: MNG-6414 Add more Apache license headers to skip downloading license … URL: https://github.com/apache/maven/pull/167 …text To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) 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] [Created] (MNG-6414) Add more Apache license header patterns to skip downloading Apache license
Sylwester Lachiewicz created MNG-6414: - Summary: Add more Apache license header patterns to skip downloading Apache license Key: MNG-6414 URL: https://issues.apache.org/jira/browse/MNG-6414 Project: Maven Issue Type: Improvement Reporter: Sylwester Lachiewicz While preparing Maven distribution maven-remote-resources-plugin try to download licenses for all dependencies. License file is not downloaded only when project/license/name is equal to "The Apache Software License, Version 2.0". Additional patterns exists and needs to be added to exception list in appended-resources/META-INF/LICENSE.vm: Apache License, Version 2.0 The Apache Software License, Version 2.0 ASLv2 Apache Public License 2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
