[jira] [Commented] (MNG-7960) Artifact collection filtering
[
https://issues.apache.org/jira/browse/MNG-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799279#comment-17799279
]
ASF GitHub Bot commented on MNG-7960:
-
gnodet commented on code in PR #1353:
URL: https://github.com/apache/maven/pull/1353#discussion_r1433547141
##
maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java:
##
@@ -406,6 +443,75 @@ public SessionBuilder
newRepositorySessionBuilder(MavenExecutionRequest request)
return session;
}
+private VersionFilter buildVersionFilter(Map configProps) {
+ArrayList filters = new ArrayList<>();
+String filterExpression = (String)
configProps.get(MAVEN_VERSION_FILTERS);
+if (filterExpression != null) {
+List expressions =
Arrays.stream(filterExpression.split(","))
+.filter(s -> s != null && !s.trim().isEmpty())
+.collect(Collectors.toList());
+for (String expression : expressions) {
+if ("h".equals(expression)) {
+filters.add(new HighestVersionFilter());
+} else if (expression.startsWith("h(") &&
expression.endsWith(")")) {
+int num = Integer.parseInt(expression.substring(2,
expression.length() - 1));
+// MRESOLVER-450
+// filters.add(new HighestVersionFilter(num));
Review Comment:
I think it's https://github.com/apache/maven-resolver/pull/401 /
MRESOLVER-460.
This PR should be moved to draft to avoid anyone forgetting it's not
finished and we need next resolver alpha.
> Artifact collection filtering
> -
>
> Key: MNG-7960
> URL: https://issues.apache.org/jira/browse/MNG-7960
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-12
>
>
> Exposed work from MRESOLVER-451 and MRESOLVER-460: allow for various
> filterings.
> User should be able to "tune" range processing. Also, as this affects
> resolution, ideally these "tuned" parameters should be stored along project,
> especially if project relies on these (ie. in {{.mvn/maven.config}}).
> Explanation: Maven is notoriously "bad" when ranges are being used. Hence,
> this issue introduces (range) version filtering support. The configuration
> accepts an "expression" (CSV) of filters. Supported filters are:
> * "h" (equivalent of "h(1)") or "h(N)" - that selects "top N" versions from
> range
> * "l" (equivalent of "l(1)") or "l(N)" - that selects "bottom N" versions
> from range
> * "s" snapshot filter: if root/project is snapshot, will allow snapshots in
> ranges, otherwise snapshot versions are filtered out (also see Resolver
> config {{aether.snapshotFilter}} present in Resolver 1.x but has no effect in
> Maven3 as it is not used).
> * "e(G:A:V)" exclusion, if range for G:A is processed, V is _excluded_ from
> range. V can be version range as well, then whole range is excluded.
> The built expressions are evaluated in-order, and filtering effect is
> accumulated. Hence, expression like "h(5),l" will return 5th highest version,
> etc.
> This depends on resolver release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7960] Version filtering [maven]
gnodet commented on code in PR #1353:
URL: https://github.com/apache/maven/pull/1353#discussion_r1433547141
##
maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java:
##
@@ -406,6 +443,75 @@ public SessionBuilder
newRepositorySessionBuilder(MavenExecutionRequest request)
return session;
}
+private VersionFilter buildVersionFilter(Map configProps) {
+ArrayList filters = new ArrayList<>();
+String filterExpression = (String)
configProps.get(MAVEN_VERSION_FILTERS);
+if (filterExpression != null) {
+List expressions =
Arrays.stream(filterExpression.split(","))
+.filter(s -> s != null && !s.trim().isEmpty())
+.collect(Collectors.toList());
+for (String expression : expressions) {
+if ("h".equals(expression)) {
+filters.add(new HighestVersionFilter());
+} else if (expression.startsWith("h(") &&
expression.endsWith(")")) {
+int num = Integer.parseInt(expression.substring(2,
expression.length() - 1));
+// MRESOLVER-450
+// filters.add(new HighestVersionFilter(num));
Review Comment:
I think it's https://github.com/apache/maven-resolver/pull/401 /
MRESOLVER-460.
This PR should be moved to draft to avoid anyone forgetting it's not
finished and we need next resolver alpha.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7982) Switch to enable transitivity in depMgr used by Maven
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799278#comment-17799278 ] ASF GitHub Bot commented on MNG-7982: - gnodet commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1865512751 > Hmm, still thinking a bit out loud but at some point it was discussed that the consumed pom would be "cleaned for central" (flatten maven plugin like etc) to ensure the consumers see it as the producer in terms of resolution, whatever version it uses, is it still in the scope? If so depMgt is maybe no more a thing transitively and then we just do what we want for maven 4, wdyt? Keeping deployed artifacts consumable by maven 3 is still the plan to day, and yes, this kinda imply we can't really bring-in things that would require a change at consumption time in maven 3. However, in Maven 4, the 4.1.0 model has a flag `preserveModelVersion` which can be used to force the usage of 4.1.0 model at deployment time. This could be used to force the trigger of the new behaviour on the consumer side, at the cost of requiring maven 4.0.0. However, I have no idea what the impact is if one builds a project with the _transitive_ dependency manager, but uses it with the _classic_ one in Maven 3. Could that break the consumer side ? > Switch to enable transitivity in depMgr used by Maven > - > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > Resolver MRESOLVER-462 that is a boolean switch (to enable or disable -- as > before -- the transitivity in depMgr). > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Switch to enable transitivity in depMgr used by Maven [maven]
gnodet commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1865512751 > Hmm, still thinking a bit out loud but at some point it was discussed that the consumed pom would be "cleaned for central" (flatten maven plugin like etc) to ensure the consumers see it as the producer in terms of resolution, whatever version it uses, is it still in the scope? If so depMgt is maybe no more a thing transitively and then we just do what we want for maven 4, wdyt? Keeping deployed artifacts consumable by maven 3 is still the plan to day, and yes, this kinda imply we can't really bring-in things that would require a change at consumption time in maven 3. However, in Maven 4, the 4.1.0 model has a flag `preserveModelVersion` which can be used to force the usage of 4.1.0 model at deployment time. This could be used to force the trigger of the new behaviour on the consumer side, at the cost of requiring maven 4.0.0. However, I have no idea what the impact is if one builds a project with the _transitive_ dependency manager, but uses it with the _classic_ one in Maven 3. Could that break the consumer side ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7985) Provide project access to modified resources / test-resources and to the executionProject
[ https://issues.apache.org/jira/browse/MNG-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7985. Fix Version/s: 4.0.0 Resolution: Fixed > Provide project access to modified resources / test-resources and to the > executionProject > - > > Key: MNG-7985 > URL: https://issues.apache.org/jira/browse/MNG-7985 > Project: Maven > Issue Type: Improvement > Components: API >Affects Versions: 4.0.0-alpha-10 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7985) Provide project access to modified resources / test-resources and to the executionProject
[ https://issues.apache.org/jira/browse/MNG-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799277#comment-17799277 ] ASF GitHub Bot commented on MNG-7985: - gnodet merged PR #1356: URL: https://github.com/apache/maven/pull/1356 > Provide project access to modified resources / test-resources and to the > executionProject > - > > Key: MNG-7985 > URL: https://issues.apache.org/jira/browse/MNG-7985 > Project: Maven > Issue Type: Improvement > Components: API >Affects Versions: 4.0.0-alpha-10 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7985] Provide project access to modified resources / test-resources and to the executionProject [maven]
gnodet merged PR #1356: URL: https://github.com/apache/maven/pull/1356 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-568) Bump plexusCompilerVersion from 2.14.1 to 2.14.2
[ https://issues.apache.org/jira/browse/MCOMPILER-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799199#comment-17799199 ] ASF GitHub Bot commented on MCOMPILER-568: -- slawekjaranowski merged PR #220: URL: https://github.com/apache/maven-compiler-plugin/pull/220 > Bump plexusCompilerVersion from 2.14.1 to 2.14.2 > > > Key: MCOMPILER-568 > URL: https://issues.apache.org/jira/browse/MCOMPILER-568 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.12.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-568) Bump plexusCompilerVersion from 2.14.1 to 2.14.2
[ https://issues.apache.org/jira/browse/MCOMPILER-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MCOMPILER-568. - Resolution: Fixed > Bump plexusCompilerVersion from 2.14.1 to 2.14.2 > > > Key: MCOMPILER-568 > URL: https://issues.apache.org/jira/browse/MCOMPILER-568 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.12.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-568] Bump plexusCompilerVersion from 2.14.1 to 2.14.2 [maven-compiler-plugin]
slawekjaranowski merged PR #220: URL: https://github.com/apache/maven-compiler-plugin/pull/220 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MCOMPILER-567) Fail to compile if the "generated-sources/annotations" does not exist
[
https://issues.apache.org/jira/browse/MCOMPILER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MCOMPILER-567.
-
Resolution: Fixed
> Fail to compile if the "generated-sources/annotations" does not exist
> -
>
> Key: MCOMPILER-567
> URL: https://issues.apache.org/jira/browse/MCOMPILER-567
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.0
>Reporter: Jorge Solórzano
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.12.1
>
>
> On some configurations (like a Kotlin project), the cleanup of the
> generated-soruces/annotations directory returns an error:
> {code:java}
> Caused by: java.lang.IllegalStateException: basedir
> /maven-compiler-plugin/target/it/MCOMPILER-XX/target/generated-sources/annotations
> does not exist
> at org.codehaus.plexus.util.DirectoryScanner.scan
> (DirectoryScanner.java:268)
> at
> org.codehaus.plexus.compiler.AbstractCompiler.getSourceFilesForSourceRoot
> (AbstractCompiler.java:168)
> at org.codehaus.plexus.compiler.AbstractCompiler.getSourceFiles
> (AbstractCompiler.java:194)
> at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
> (JavacCompiler.java:138)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1187)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:212)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348){code}
>
> I didn't catch this earlier since I don't use Kotlin and on a normal project,
> this should not be an issue since the javac documentation mentions that the
> directory, and any necessary subdirectories, will be created if they do not
> already exist.
> But on a somewhat modified project that compiles kotlin source code, this
> triggers an issue on plexus-compiler where the generated-soruces directory
> does not exist.
>
> This might be related to issue MCOMPILER-538, where it claims that generated
> source root is not required for javac, but additional confirmation is
> required.
>
> The fix will be to create the generated sources directory to preserve the
> current behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-567) Fail to compile if the "generated-sources/annotations" does not exist
[
https://issues.apache.org/jira/browse/MCOMPILER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799192#comment-17799192
]
ASF GitHub Bot commented on MCOMPILER-567:
--
slawekjaranowski merged PR #218:
URL: https://github.com/apache/maven-compiler-plugin/pull/218
> Fail to compile if the "generated-sources/annotations" does not exist
> -
>
> Key: MCOMPILER-567
> URL: https://issues.apache.org/jira/browse/MCOMPILER-567
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.0
>Reporter: Jorge Solórzano
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.12.1
>
>
> On some configurations (like a Kotlin project), the cleanup of the
> generated-soruces/annotations directory returns an error:
> {code:java}
> Caused by: java.lang.IllegalStateException: basedir
> /maven-compiler-plugin/target/it/MCOMPILER-XX/target/generated-sources/annotations
> does not exist
> at org.codehaus.plexus.util.DirectoryScanner.scan
> (DirectoryScanner.java:268)
> at
> org.codehaus.plexus.compiler.AbstractCompiler.getSourceFilesForSourceRoot
> (AbstractCompiler.java:168)
> at org.codehaus.plexus.compiler.AbstractCompiler.getSourceFiles
> (AbstractCompiler.java:194)
> at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
> (JavacCompiler.java:138)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1187)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:212)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348){code}
>
> I didn't catch this earlier since I don't use Kotlin and on a normal project,
> this should not be an issue since the javac documentation mentions that the
> directory, and any necessary subdirectories, will be created if they do not
> already exist.
> But on a somewhat modified project that compiles kotlin source code, this
> triggers an issue on plexus-compiler where the generated-soruces directory
> does not exist.
>
> This might be related to issue MCOMPILER-538, where it claims that generated
> source root is not required for javac, but additional confirmation is
> required.
>
> The fix will be to create the generated sources directory to preserve the
> current behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-567] - Fail to compile if the generated-sources/annotation… [maven-compiler-plugin]
slawekjaranowski merged PR #218: URL: https://github.com/apache/maven-compiler-plugin/pull/218 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MCOMPILER-568) Bump plexusCompilerVersion from 2.14.1 to 2.14.2
Slawomir Jaranowski created MCOMPILER-568: - Summary: Bump plexusCompilerVersion from 2.14.1 to 2.14.2 Key: MCOMPILER-568 URL: https://issues.apache.org/jira/browse/MCOMPILER-568 Project: Maven Compiler Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.12.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump plexusCompilerVersion from 2.14.1 to 2.14.2 [maven-compiler-plugin]
dependabot[bot] opened a new pull request, #220: URL: https://github.com/apache/maven-compiler-plugin/pull/220 Bumps `plexusCompilerVersion` from 2.14.1 to 2.14.2. Updates `org.codehaus.plexus:plexus-compiler-api` from 2.14.1 to 2.14.2 Release notes Sourced from https://github.com/codehaus-plexus/plexus-compiler/releases;>org.codehaus.plexus:plexus-compiler-api's releases. 2.14.2 Bug Fixes Return empty list for not existing source root location (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/338;>#338) https://github.com/slawekjaranowski;>@slawekjaranowski Improve javac error output parsing - Fix https://redirect.github.com/codehaus-plexus/plexus-compiler/issues/336;>#336 (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/337;>#337) https://github.com/kriegaex;>@kriegaex Dependency updates Bump org.apache.maven.plugins:maven-compiler-plugin from 3.11.0 to 3.12.0 (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/339;>#339) https://github.com/dependabot;>@dependabot Bump com.google.guava:guava from 32.1.3-jre to 33.0.0-jre (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/340;>#340) https://github.com/dependabot;>@dependabot Bump org.codehaus.plexus:plexus-testing from 1.2.0 to 1.3.0 (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/335;>#335) https://github.com/dependabot;>@dependabot Commits https://github.com/codehaus-plexus/plexus-compiler/commit/e4e73d0225bae664c67295b8a8a6e8d115692dd0;>e4e73d0 [maven-release-plugin] prepare release plexus-compiler-2.14.2 https://github.com/codehaus-plexus/plexus-compiler/commit/5a7268e9dec1c42ff6ef1bf86dc3c529c3ca9551;>5a7268e Bump org.apache.maven.plugins:maven-compiler-plugin from 3.11.0 to 3.12.0 (https://redirect.github.com/codehaus-plexus/plexus-compiler/issues/339;>#339) https://github.com/codehaus-plexus/plexus-compiler/commit/36ead1f948b595bc75ca30a044aa77dda9cf53ab;>36ead1f Return empty list for not existing source root location https://github.com/codehaus-plexus/plexus-compiler/commit/b5631da2f56529027a21a0a981b09369cd394da2;>b5631da Improve javac error output parsing - Fix https://redirect.github.com/codehaus-plexus/plexus-compiler/issues/336;>#336 (https://redirect.github.com/codehaus-plexus/plexus-compiler/issues/337;>#337) https://github.com/codehaus-plexus/plexus-compiler/commit/b37ca3398ccd5d7cf62c233c1b29d8d8843e6194;>b37ca33 Bump com.google.guava:guava from 32.1.3-jre to 33.0.0-jre https://github.com/codehaus-plexus/plexus-compiler/commit/5f3ca241954dd99edb511f21860c6d6f5a85a483;>5f3ca24 Bump org.codehaus.plexus:plexus-testing from 1.2.0 to 1.3.0 https://github.com/codehaus-plexus/plexus-compiler/commit/9de0910a4bf112244fba10bb8678a454d37e3188;>9de0910 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-compiler/compare/plexus-compiler-2.14.1...plexus-compiler-2.14.2;>compare view Updates `org.codehaus.plexus:plexus-compiler-manager` from 2.14.1 to 2.14.2 Release notes Sourced from https://github.com/codehaus-plexus/plexus-compiler/releases;>org.codehaus.plexus:plexus-compiler-manager's releases. 2.14.2 Bug Fixes Return empty list for not existing source root location (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/338;>#338) https://github.com/slawekjaranowski;>@slawekjaranowski Improve javac error output parsing - Fix https://redirect.github.com/codehaus-plexus/plexus-compiler/issues/336;>#336 (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/337;>#337) https://github.com/kriegaex;>@kriegaex Dependency updates Bump org.apache.maven.plugins:maven-compiler-plugin from 3.11.0 to 3.12.0 (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/339;>#339) https://github.com/dependabot;>@dependabot Bump com.google.guava:guava from 32.1.3-jre to 33.0.0-jre (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/340;>#340) https://github.com/dependabot;>@dependabot Bump org.codehaus.plexus:plexus-testing from 1.2.0 to 1.3.0 (https://redirect.github.com/codehaus-plexus/plexus-compiler/pull/335;>#335) https://github.com/dependabot;>@dependabot Commits https://github.com/codehaus-plexus/plexus-compiler/commit/e4e73d0225bae664c67295b8a8a6e8d115692dd0;>e4e73d0 [maven-release-plugin] prepare release plexus-compiler-2.14.2 https://github.com/codehaus-plexus/plexus-compiler/commit/5a7268e9dec1c42ff6ef1bf86dc3c529c3ca9551;>5a7268e Bump org.apache.maven.plugins:maven-compiler-plugin from 3.11.0 to 3.12.0 (https://redirect.github.com/codehaus-plexus/plexus-compiler/issues/339;>#339) https://github.com/codehaus-plexus/plexus-compiler/commit/36ead1f948b595bc75ca30a044aa77dda9cf53ab;>36ead1f Return empty list for
[jira] [Updated] (MCOMPILER-538) Do not add target/generated-sources/annotations to the source roots
[
https://issues.apache.org/jira/browse/MCOMPILER-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MCOMPILER-538:
--
Fix Version/s: waiting-for-feedback
(was: 3.12.1)
> Do not add target/generated-sources/annotations to the source roots
> ---
>
> Key: MCOMPILER-538
> URL: https://issues.apache.org/jira/browse/MCOMPILER-538
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: Daniel Mensinger
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Adding the generated source root ({{target/generated-sources/annotations}})
> is not required for javac. Additionally adding the generated source root
> results in compilation errors with annotation processors generating code
> unless the generated-sources dir is cleaned.
> Specifically, the following steps result in compilation errors:
> # run {{mvn clean}}
> # Modify a source file that is consumed by the annotation processor so that
> there is a compilation error, but the annotation processor still runs (add or
> remove a parameter in a method call).
> # run {{mvn compile}} --> the generated file exists but there is no class
> file for the source file.
> # Fix the "bug" from step 2
> # run {{mvn compile}} again --> compilation should succeed, but it fails.
>
> Example code:
> [https://github.com/mensinda/quarkus-stuff/tree/annotationProcessingTest]
> Use the {{annotationProcessingTest}} branch!
> For step 2 this change can be used:
> {code:java}
> diff --git a/code/src/main/java/bar/MyAnnotatedClass.java
> b/code/src/main/java/bar/MyAnnotatedClass.java
> index bbfef7a..a303924 100644
> --- a/code/src/main/java/bar/MyAnnotatedClass.java
> +++ b/code/src/main/java/bar/MyAnnotatedClass.java
> @@ -4,7 +4,7 @@ import foo.MyAnnotation;
> @MyAnnotation
> public class MyAnnotatedClass {
> -MyGeneratedClass generatedClass = new MyGeneratedClass();
> +MyGeneratedClass generatedClass = new MyGeneratedClass(false);
> // foo
> {code}
>
> To see that *not* adding {{target/generated-sources/annotations}} helps run
> {{mvn -X compile}} and copy the {{Command line options:}}. Then run {{javac}}
> manually, but remove the {{target/generated-sources/annotations}} from the
> {{-sourcepath}} list, but *not* the {{-s}} parameter.
>
> PR with a fix: https://github.com/apache/maven-compiler-plugin/pull/191
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-538) Do not add target/generated-sources/annotations to the source roots
[
https://issues.apache.org/jira/browse/MCOMPILER-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799180#comment-17799180
]
Slawomir Jaranowski commented on MCOMPILER-538:
---
[~mensinda] I have tested your patch with provided project and I have:
{noformat}
generatedSourcesInJavacArgs.sh
...
[INFO] --- compiler:3.12.1-SNAPSHOT:compile (default-compile) @ code ---
[INFO] Compiling 2 source files with javac [forked debug deprecation target 17]
to target/classes
[INFO] -
[WARNING] COMPILATION WARNING :
[INFO] -
[WARNING] [options] system modules path not set in conjunction with -source 17
[INFO] 1 warning
[INFO] -
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] java.lang.RuntimeException: javax.annotation.processing.FilerException:
Attempt to recreate a file for type bar.MyGeneratedClass
at foo.MyProcessor.process(MyProcessor.java:24)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1021)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:937)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1265)
at
jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1380)
at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1272)
at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
Caused by: javax.annotation.processing.FilerException: Attempt to recreate a
file for type bar.MyGeneratedClass
at
jdk.compiler/com.sun.tools.javac.processing.JavacFiler.checkNameAndExistence(JavacFiler.java:741)
at
jdk.compiler/com.sun.tools.javac.processing.JavacFiler.createSourceOrClassFile(JavacFiler.java:498)
at
jdk.compiler/com.sun.tools.javac.processing.JavacFiler.createSourceFile(JavacFiler.java:435)
at foo.MyProcessor.generate(MyProcessor.java:40)
at foo.MyProcessor.process(MyProcessor.java:22)
... 10 more
{noformat}
So looks like not resolve a problem
We should have an IT - which can reproduce a problem
> Do not add target/generated-sources/annotations to the source roots
> ---
>
> Key: MCOMPILER-538
> URL: https://issues.apache.org/jira/browse/MCOMPILER-538
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: Daniel Mensinger
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.12.1
>
>
> Adding the generated source root ({{target/generated-sources/annotations}})
> is not required for javac. Additionally adding the generated source root
> results in compilation errors with annotation processors generating code
> unless the generated-sources dir is cleaned.
> Specifically, the following steps result in compilation errors:
> # run {{mvn clean}}
> # Modify a source file that is consumed by the annotation processor so that
> there is a compilation error, but the annotation processor still runs (add or
> remove a parameter in a method call).
> # run {{mvn compile}} --> the generated file exists but there is no class
> file for the source file.
> # Fix the "bug" from step 2
> # run {{mvn compile}} again --> compilation should succeed, but it fails.
>
> Example code:
> [https://github.com/mensinda/quarkus-stuff/tree/annotationProcessingTest]
> Use the {{annotationProcessingTest}} branch!
> For step 2 this change can be used:
> {code:java}
> diff --git a/code/src/main/java/bar/MyAnnotatedClass.java
> b/code/src/main/java/bar/MyAnnotatedClass.java
> index bbfef7a..a303924 100644
> --- a/code/src/main/java/bar/MyAnnotatedClass.java
> +++ b/code/src/main/java/bar/MyAnnotatedClass.java
> @@ -4,7 +4,7 @@ import foo.MyAnnotation;
> @MyAnnotation
> public class MyAnnotatedClass {
> -MyGeneratedClass generatedClass = new MyGeneratedClass();
> +MyGeneratedClass generatedClass = new MyGeneratedClass(false);
> // foo
> {code}
>
> To see that *not* adding
[jira] [Commented] (MCOMPILER-561) Add new rebuild detection for bytecode changes
[ https://issues.apache.org/jira/browse/MCOMPILER-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799162#comment-17799162 ] ASF GitHub Bot commented on MCOMPILER-561: -- jorsol closed pull request #219: [MCOMPILER-561] - Add new rebuild detection for bytecode changes URL: https://github.com/apache/maven-compiler-plugin/pull/219 > Add new rebuild detection for bytecode changes > -- > > Key: MCOMPILER-561 > URL: https://issues.apache.org/jira/browse/MCOMPILER-561 > Project: Maven Compiler Plugin > Issue Type: New Feature >Affects Versions: 3.11.0, 3.12.0 >Reporter: Jorge Solórzano >Priority: Major > > If the source code changes the bytecode version, it should trigger a rebuild. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-561) Add new rebuild detection for bytecode changes
[
https://issues.apache.org/jira/browse/MCOMPILER-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799163#comment-17799163
]
ASF GitHub Bot commented on MCOMPILER-561:
--
jorsol commented on code in PR #219:
URL:
https://github.com/apache/maven-compiler-plugin/pull/219#discussion_r1433148927
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1842,6 +1851,48 @@ private boolean
hasInputFileTreeChanged(IncrementalBuildHelper ibh, Set in
return inputTreeChanges.hasChanged();
}
+private static final int MAX_FILE_WALK_LIMIT = 20;
+
+/**
+ * Performs a check on compiled class files to ensure that the bytecode
version
+ * hasn't changed between runs.
+ *
+ * This is limited to check a maximum of {@link #MAX_FILE_WALK_LIMIT}.
+ *
+ * @return true if a bytecode version differs from the actual release
version.
+ */
+private boolean hasBytecodeChanged() {
+String currentVersion = getVersionRelease();
+JavaVersion javaVersion = JavaVersion.parse(currentVersion).asMajor();
+
+try (Stream walk = Files.walk(getOutputDirectory().toPath())) {
+Map pathVersionMap = walk.filter(file
-> "class"
+
.equals(FileUtils.extension(file.getFileName().toString(
+.limit(MAX_FILE_WALK_LIMIT)
+.collect(Collectors.toMap(Function.identity(),
JavaClassfileVersion::of));
Review Comment:
That's a really good approach, I'm making complex bytecode checks when
simply storing the current JDK, and verifying next time would do the trick.
Closing this in favor of that approach (will open a new PR later).
> Add new rebuild detection for bytecode changes
> --
>
> Key: MCOMPILER-561
> URL: https://issues.apache.org/jira/browse/MCOMPILER-561
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.11.0, 3.12.0
>Reporter: Jorge Solórzano
>Priority: Major
>
> If the source code changes the bytecode version, it should trigger a rebuild.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-561] - Add new rebuild detection for bytecode changes [maven-compiler-plugin]
jorsol closed pull request #219: [MCOMPILER-561] - Add new rebuild detection for bytecode changes URL: https://github.com/apache/maven-compiler-plugin/pull/219 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MCOMPILER-561] - Add new rebuild detection for bytecode changes [maven-compiler-plugin]
jorsol commented on code in PR #219:
URL:
https://github.com/apache/maven-compiler-plugin/pull/219#discussion_r1433148927
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1842,6 +1851,48 @@ private boolean
hasInputFileTreeChanged(IncrementalBuildHelper ibh, Set in
return inputTreeChanges.hasChanged();
}
+private static final int MAX_FILE_WALK_LIMIT = 20;
+
+/**
+ * Performs a check on compiled class files to ensure that the bytecode
version
+ * hasn't changed between runs.
+ *
+ * This is limited to check a maximum of {@link #MAX_FILE_WALK_LIMIT}.
+ *
+ * @return true if a bytecode version differs from the actual release
version.
+ */
+private boolean hasBytecodeChanged() {
+String currentVersion = getVersionRelease();
+JavaVersion javaVersion = JavaVersion.parse(currentVersion).asMajor();
+
+try (Stream walk = Files.walk(getOutputDirectory().toPath())) {
+Map pathVersionMap = walk.filter(file
-> "class"
+
.equals(FileUtils.extension(file.getFileName().toString(
+.limit(MAX_FILE_WALK_LIMIT)
+.collect(Collectors.toMap(Function.identity(),
JavaClassfileVersion::of));
Review Comment:
That's a really good approach, I'm making complex bytecode checks when
simply storing the current JDK, and verifying next time would do the trick.
Closing this in favor of that approach (will open a new PR later).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MCOMPILER-561) Add new rebuild detection for bytecode changes
[
https://issues.apache.org/jira/browse/MCOMPILER-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799160#comment-17799160
]
ASF GitHub Bot commented on MCOMPILER-561:
--
slawekjaranowski commented on code in PR #219:
URL:
https://github.com/apache/maven-compiler-plugin/pull/219#discussion_r1433140742
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1842,6 +1851,48 @@ private boolean
hasInputFileTreeChanged(IncrementalBuildHelper ibh, Set in
return inputTreeChanges.hasChanged();
}
+private static final int MAX_FILE_WALK_LIMIT = 20;
+
+/**
+ * Performs a check on compiled class files to ensure that the bytecode
version
+ * hasn't changed between runs.
+ *
+ * This is limited to check a maximum of {@link #MAX_FILE_WALK_LIMIT}.
+ *
+ * @return true if a bytecode version differs from the actual release
version.
+ */
+private boolean hasBytecodeChanged() {
+String currentVersion = getVersionRelease();
+JavaVersion javaVersion = JavaVersion.parse(currentVersion).asMajor();
+
+try (Stream walk = Files.walk(getOutputDirectory().toPath())) {
+Map pathVersionMap = walk.filter(file
-> "class"
+
.equals(FileUtils.extension(file.getFileName().toString(
+.limit(MAX_FILE_WALK_LIMIT)
+.collect(Collectors.toMap(Function.identity(),
JavaClassfileVersion::of));
Review Comment:
Maybe instead of checking bytecode of classes we can store current JDK
version used to compile and next time verify if is the same.
We also should add an IT for multi-releases compilation.
> Add new rebuild detection for bytecode changes
> --
>
> Key: MCOMPILER-561
> URL: https://issues.apache.org/jira/browse/MCOMPILER-561
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 3.11.0, 3.12.0
>Reporter: Jorge Solórzano
>Priority: Major
>
> If the source code changes the bytecode version, it should trigger a rebuild.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-561] - Add new rebuild detection for bytecode changes [maven-compiler-plugin]
slawekjaranowski commented on code in PR #219:
URL:
https://github.com/apache/maven-compiler-plugin/pull/219#discussion_r1433140742
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1842,6 +1851,48 @@ private boolean
hasInputFileTreeChanged(IncrementalBuildHelper ibh, Set in
return inputTreeChanges.hasChanged();
}
+private static final int MAX_FILE_WALK_LIMIT = 20;
+
+/**
+ * Performs a check on compiled class files to ensure that the bytecode
version
+ * hasn't changed between runs.
+ *
+ * This is limited to check a maximum of {@link #MAX_FILE_WALK_LIMIT}.
+ *
+ * @return true if a bytecode version differs from the actual release
version.
+ */
+private boolean hasBytecodeChanged() {
+String currentVersion = getVersionRelease();
+JavaVersion javaVersion = JavaVersion.parse(currentVersion).asMajor();
+
+try (Stream walk = Files.walk(getOutputDirectory().toPath())) {
+Map pathVersionMap = walk.filter(file
-> "class"
+
.equals(FileUtils.extension(file.getFileName().toString(
+.limit(MAX_FILE_WALK_LIMIT)
+.collect(Collectors.toMap(Function.identity(),
JavaClassfileVersion::of));
Review Comment:
Maybe instead of checking bytecode of classes we can store current JDK
version used to compile and next time verify if is the same.
We also should add an IT for multi-releases compilation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MJARSIGNER-69) Verify failFast
[ https://issues.apache.org/jira/browse/MJARSIGNER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MJARSIGNER-69: Issue Type: New Feature (was: Improvement) > Verify failFast > --- > > Key: MJARSIGNER-69 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-69 > Project: Maven Jar Signer Plugin > Issue Type: New Feature >Reporter: Delany >Priority: Major > > When I verify a directory of jars and errorWhenNotSigned=true I'd like the > option of failing after verifying all jars. > Same as > [https://maven.apache.org/enforcer/maven-enforcer-plugin/enforce-mojo.html#failFast] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJARSIGNER-48) Make Jar Signer plugin :sign goal threadsafe
[
https://issues.apache.org/jira/browse/MJARSIGNER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MJARSIGNER-48.
-
Resolution: Fixed
> Make Jar Signer plugin :sign goal threadsafe
>
>
> Key: MJARSIGNER-48
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-48
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Kaloyan Raev
>Priority: Major
> Labels: build
> Fix For: 3.1.0
>
>
> Right now when you execute mvn *-T 4* maven-jarsigner-plugin:1.4:sign you get
> a warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in uDecideSM:
> [WARNING] org.apache.maven.plugins:maven-jarsigner-plugin:1.4
> [WARNING] *
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJARSIGNER-48) Make Jar Signer plugin :sign goal threadsafe
[
https://issues.apache.org/jira/browse/MJARSIGNER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MJARSIGNER-48.
---
> Make Jar Signer plugin :sign goal threadsafe
>
>
> Key: MJARSIGNER-48
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-48
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Kaloyan Raev
>Priority: Major
> Labels: build
> Fix For: 3.1.0
>
>
> Right now when you execute mvn *-T 4* maven-jarsigner-plugin:1.4:sign you get
> a warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in uDecideSM:
> [WARNING] org.apache.maven.plugins:maven-jarsigner-plugin:1.4
> [WARNING] *
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJARSIGNER-48) Make Jar Signer plugin :sign goal threadsafe
[
https://issues.apache.org/jira/browse/MJARSIGNER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799153#comment-17799153
]
ASF GitHub Bot commented on MJARSIGNER-48:
--
elharo merged PR #2:
URL: https://github.com/apache/maven-jarsigner-plugin/pull/2
> Make Jar Signer plugin :sign goal threadsafe
>
>
> Key: MJARSIGNER-48
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-48
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Kaloyan Raev
>Priority: Major
> Labels: build
> Fix For: 3.1.0
>
>
> Right now when you execute mvn *-T 4* maven-jarsigner-plugin:1.4:sign you get
> a warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in uDecideSM:
> [WARNING] org.apache.maven.plugins:maven-jarsigner-plugin:1.4
> [WARNING] *
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJARSIGNER-48] Mark verify and sign Mojos thread safe [maven-jarsigner-plugin]
elharo merged PR #2: URL: https://github.com/apache/maven-jarsigner-plugin/pull/2 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Switch to enable transitivity in depMgr used by Maven
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799137#comment-17799137 ] ASF GitHub Bot commented on MNG-7982: - rmannibucau commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864990604 Hmm, still thinking a bit out loud but at some point it was discussed that the consumed pom would be "cleaned for central" (flatten maven plugin like etc) to ensure the consumers see it as the producer in terms of resolution, whatever version it uses, is it still in the scope? If so depMgt is maybe no more a thing transitively and then we just do what we want for maven 4, wdyt? > Switch to enable transitivity in depMgr used by Maven > - > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > Resolver MRESOLVER-462 that is a boolean switch (to enable or disable -- as > before -- the transitivity in depMgr). > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Switch to enable transitivity in depMgr used by Maven [maven]
rmannibucau commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864990604 Hmm, still thinking a bit out loud but at some point it was discussed that the consumed pom would be "cleaned for central" (flatten maven plugin like etc) to ensure the consumers see it as the producer in terms of resolution, whatever version it uses, is it still in the scope? If so depMgt is maybe no more a thing transitively and then we just do what we want for maven 4, wdyt? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7983) Update to Slf4j 2.x
[ https://issues.apache.org/jira/browse/MNG-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799134#comment-17799134 ] Guillaume Nodet commented on MNG-7983: -- It's not so easy, as [https://jira.qos.ch/browse/SLF4J-394] which was needed for maven to colorise the levels is broken with slf4j-simple 2.x. We could re-implement the logger completely... > Update to Slf4j 2.x > --- > > Key: MNG-7983 > URL: https://issues.apache.org/jira/browse/MNG-7983 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7957) Expose checksum service on API
[
https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799129#comment-17799129
]
ASF GitHub Bot commented on MNG-7957:
-
cstamas commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1433042768
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultChecksumAlgorithmService.java:
##
@@ -0,0 +1,201 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.ByteBuffer;
+import java.nio.file.Path;
+import java.util.*;
+import java.util.stream.Collectors;
+
+import org.apache.maven.api.services.*;
+import org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmFactory;
+import
org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmFactorySelector;
+import org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmHelper;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+@Named
+@Singleton
+public class DefaultChecksumAlgorithmService implements
ChecksumAlgorithmService {
+private final ChecksumAlgorithmFactorySelector
checksumAlgorithmFactorySelector;
+
+@Inject
+public DefaultChecksumAlgorithmService(ChecksumAlgorithmFactorySelector
checksumAlgorithmFactorySelector) {
+this.checksumAlgorithmFactorySelector =
+nonNull(checksumAlgorithmFactorySelector,
"checksumAlgorithmFactorySelector");
+}
+
+@Override
+public ChecksumAlgorithm select(String algorithmName) {
+nonNull(algorithmName, "algorithmName");
+return new
DefaultChecksumAlgorithm(checksumAlgorithmFactorySelector.select(algorithmName));
Review Comment:
checksumAlgorithmFactorySelector throws IllegalArgumentEx, as documented
> Expose checksum service on API
> --
>
> Key: MNG-7957
> URL: https://issues.apache.org/jira/browse/MNG-7957
> Project: Maven
> Issue Type: Dependency upgrade
> Components: API
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-11
>
>
> Resolver since 1.8 has extensible checksum SPI:
> [https://maven.apache.org/resolver/about-checksums.html]
> I think it would be worth to expose that not directly, but via some sort of
> Service in new Maven 4 API?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7957] Checksum API (backed by Resolver) [maven]
cstamas commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1433042768
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultChecksumAlgorithmService.java:
##
@@ -0,0 +1,201 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.ByteBuffer;
+import java.nio.file.Path;
+import java.util.*;
+import java.util.stream.Collectors;
+
+import org.apache.maven.api.services.*;
+import org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmFactory;
+import
org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmFactorySelector;
+import org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmHelper;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+@Named
+@Singleton
+public class DefaultChecksumAlgorithmService implements
ChecksumAlgorithmService {
+private final ChecksumAlgorithmFactorySelector
checksumAlgorithmFactorySelector;
+
+@Inject
+public DefaultChecksumAlgorithmService(ChecksumAlgorithmFactorySelector
checksumAlgorithmFactorySelector) {
+this.checksumAlgorithmFactorySelector =
+nonNull(checksumAlgorithmFactorySelector,
"checksumAlgorithmFactorySelector");
+}
+
+@Override
+public ChecksumAlgorithm select(String algorithmName) {
+nonNull(algorithmName, "algorithmName");
+return new
DefaultChecksumAlgorithm(checksumAlgorithmFactorySelector.select(algorithmName));
Review Comment:
checksumAlgorithmFactorySelector throws IllegalArgumentEx, as documented
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7957) Expose checksum service on API
[
https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799128#comment-17799128
]
ASF GitHub Bot commented on MNG-7957:
-
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1433034653
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultChecksumAlgorithmService.java:
##
@@ -0,0 +1,201 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.ByteBuffer;
+import java.nio.file.Path;
+import java.util.*;
+import java.util.stream.Collectors;
+
+import org.apache.maven.api.services.*;
+import org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmFactory;
+import
org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmFactorySelector;
+import org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmHelper;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+@Named
+@Singleton
+public class DefaultChecksumAlgorithmService implements
ChecksumAlgorithmService {
+private final ChecksumAlgorithmFactorySelector
checksumAlgorithmFactorySelector;
+
+@Inject
+public DefaultChecksumAlgorithmService(ChecksumAlgorithmFactorySelector
checksumAlgorithmFactorySelector) {
+this.checksumAlgorithmFactorySelector =
+nonNull(checksumAlgorithmFactorySelector,
"checksumAlgorithmFactorySelector");
+}
+
+@Override
+public ChecksumAlgorithm select(String algorithmName) {
+nonNull(algorithmName, "algorithmName");
+return new
DefaultChecksumAlgorithm(checksumAlgorithmFactorySelector.select(algorithmName));
Review Comment:
What if the algorithm is not found ?
> Expose checksum service on API
> --
>
> Key: MNG-7957
> URL: https://issues.apache.org/jira/browse/MNG-7957
> Project: Maven
> Issue Type: Dependency upgrade
> Components: API
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-11
>
>
> Resolver since 1.8 has extensible checksum SPI:
> [https://maven.apache.org/resolver/about-checksums.html]
> I think it would be worth to expose that not directly, but via some sort of
> Service in new Maven 4 API?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7957] Checksum API (backed by Resolver) [maven]
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1433034653
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultChecksumAlgorithmService.java:
##
@@ -0,0 +1,201 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.ByteBuffer;
+import java.nio.file.Path;
+import java.util.*;
+import java.util.stream.Collectors;
+
+import org.apache.maven.api.services.*;
+import org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmFactory;
+import
org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmFactorySelector;
+import org.eclipse.aether.spi.connector.checksum.ChecksumAlgorithmHelper;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+@Named
+@Singleton
+public class DefaultChecksumAlgorithmService implements
ChecksumAlgorithmService {
+private final ChecksumAlgorithmFactorySelector
checksumAlgorithmFactorySelector;
+
+@Inject
+public DefaultChecksumAlgorithmService(ChecksumAlgorithmFactorySelector
checksumAlgorithmFactorySelector) {
+this.checksumAlgorithmFactorySelector =
+nonNull(checksumAlgorithmFactorySelector,
"checksumAlgorithmFactorySelector");
+}
+
+@Override
+public ChecksumAlgorithm select(String algorithmName) {
+nonNull(algorithmName, "algorithmName");
+return new
DefaultChecksumAlgorithm(checksumAlgorithmFactorySelector.select(algorithmName));
Review Comment:
What if the algorithm is not found ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MJARSIGNER-48) Make Jar Signer plugin :sign goal threadsafe
[
https://issues.apache.org/jira/browse/MJARSIGNER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799126#comment-17799126
]
ASF GitHub Bot commented on MJARSIGNER-48:
--
lasselindqvist commented on PR #2:
URL:
https://github.com/apache/maven-jarsigner-plugin/pull/2#issuecomment-1864918002
It was one day late, but rebased and should be mergeable now.
> Make Jar Signer plugin :sign goal threadsafe
>
>
> Key: MJARSIGNER-48
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-48
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Kaloyan Raev
>Priority: Major
> Labels: build
> Fix For: 3.1.0
>
>
> Right now when you execute mvn *-T 4* maven-jarsigner-plugin:1.4:sign you get
> a warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in uDecideSM:
> [WARNING] org.apache.maven.plugins:maven-jarsigner-plugin:1.4
> [WARNING] *
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJARSIGNER-48] Mark verify and sign Mojos thread safe [maven-jarsigner-plugin]
lasselindqvist commented on PR #2: URL: https://github.com/apache/maven-jarsigner-plugin/pull/2#issuecomment-1864918002 It was one day late, but rebased and should be mergeable now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7957) Expose checksum service on API
[ https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7957: - Component/s: API > Expose checksum service on API > -- > > Key: MNG-7957 > URL: https://issues.apache.org/jira/browse/MNG-7957 > Project: Maven > Issue Type: Dependency upgrade > Components: API >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > > Resolver since 1.8 has extensible checksum SPI: > [https://maven.apache.org/resolver/about-checksums.html] > I think it would be worth to expose that not directly, but via some sort of > Service in new Maven 4 API? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7957) Expose checksum service on API
[ https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7957: - Fix Version/s: 4.0.0 4.0.0-alpha-11 (was: 4.0.x-candidate) > Expose checksum service on API > -- > > Key: MNG-7957 > URL: https://issues.apache.org/jira/browse/MNG-7957 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > > Resolver since 1.8 has extensible checksum SPI: > [https://maven.apache.org/resolver/about-checksums.html] > I think it would be worth to expose that not directly, but via some sort of > Service in new Maven 4 API? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7957) Expose checksum service on API
[ https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-7957: Assignee: Tamas Cservenak > Expose checksum service on API > -- > > Key: MNG-7957 > URL: https://issues.apache.org/jira/browse/MNG-7957 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.x-candidate > > > Resolver since 1.8 has extensible checksum SPI: > [https://maven.apache.org/resolver/about-checksums.html] > I think it would be worth to expose that not directly, but via some sort of > Service in new Maven 4 API? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7957) Expose checksum service on API
[
https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799100#comment-17799100
]
ASF GitHub Bot commented on MNG-7957:
-
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1432965303
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,160 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.ByteBuffer;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a collection of {@link ChecksumAlgorithm} in same order as
algorithm names are ordered, or throws if
+ * any of the algorithm name is not supported. The returned collection has
equal count of elements as passed in
+ * collection of names, and if names contains duplicated elements, the
returned list of algorithms will have
+ * duplicates as well.
+ *
+ * @throws IllegalArgumentException if any asked algorithm name is not
supported.
+ * @throws NullPointerException if passed in list of names is {@code null}.
+ */
+@Nonnull
+Collection selectCollection(@Nonnull Collection
algorithmNames);
Review Comment:
Would `select` be sufficient for the method name ?
> Expose checksum service on API
> --
>
> Key: MNG-7957
> URL: https://issues.apache.org/jira/browse/MNG-7957
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Resolver since 1.8 has extensible checksum SPI:
> [https://maven.apache.org/resolver/about-checksums.html]
> I think it would be worth to expose that not directly, but via some sort of
> Service in new Maven 4 API?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7957] Checksum API (backed by Resolver) [maven]
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1432965303
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,160 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.ByteBuffer;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a collection of {@link ChecksumAlgorithm} in same order as
algorithm names are ordered, or throws if
+ * any of the algorithm name is not supported. The returned collection has
equal count of elements as passed in
+ * collection of names, and if names contains duplicated elements, the
returned list of algorithms will have
+ * duplicates as well.
+ *
+ * @throws IllegalArgumentException if any asked algorithm name is not
supported.
+ * @throws NullPointerException if passed in list of names is {@code null}.
+ */
+@Nonnull
+Collection selectCollection(@Nonnull Collection
algorithmNames);
Review Comment:
Would `select` be sufficient for the method name ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7957) Expose checksum service on API
[
https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799098#comment-17799098
]
ASF GitHub Bot commented on MNG-7957:
-
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1432954888
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,87 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a list of {@link ChecksumAlgorithm} in same order as algorithm
names are ordered, or throws if any of the
+ * algorithm name is not supported. The returned list has equal count of
elements as passed in collection of names,
+ * and if names contains duplicated elements, the returned list of
algorithms will have duplicates as well.
+ *
+ * @throws IllegalArgumentException if any asked algorithm name is not
supported.
+ * @throws NullPointerException if passed in list of names is {@code null}.
+ */
+@Nonnull
+Collection selectList(@Nonnull Collection
algorithmNames);
+
+/**
+ * Returns immutable collection of all supported algorithm names.
+ */
+@Nonnull
+Collection getChecksumAlgorithmNames();
+
+/**
+ * Calculates checksums for specified data.
+ *
+ * @param dataThe content for which to calculate checksums, must
not be {@code null}.
+ * @param algorithms The checksum algorithm factories to use, must not be
{@code null}.
+ * @return The calculated checksums, indexed by algorithm name, or the
exception that occurred while trying to
+ * calculate it, never {@code null}.
+ * @throws IOException In case of any problem.
+ */
+@Nonnull
+Map calculate(@Nonnull byte[] data, @Nonnull
Collection algorithms)
Review Comment:
The returned Map is not really useful. It should be
Map`
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,87 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws
Re: [PR] [MNG-7957] Checksum API (backed by Resolver) [maven]
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1432954888
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,87 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a list of {@link ChecksumAlgorithm} in same order as algorithm
names are ordered, or throws if any of the
+ * algorithm name is not supported. The returned list has equal count of
elements as passed in collection of names,
+ * and if names contains duplicated elements, the returned list of
algorithms will have duplicates as well.
+ *
+ * @throws IllegalArgumentException if any asked algorithm name is not
supported.
+ * @throws NullPointerException if passed in list of names is {@code null}.
+ */
+@Nonnull
+Collection selectList(@Nonnull Collection
algorithmNames);
+
+/**
+ * Returns immutable collection of all supported algorithm names.
+ */
+@Nonnull
+Collection getChecksumAlgorithmNames();
+
+/**
+ * Calculates checksums for specified data.
+ *
+ * @param dataThe content for which to calculate checksums, must
not be {@code null}.
+ * @param algorithms The checksum algorithm factories to use, must not be
{@code null}.
+ * @return The calculated checksums, indexed by algorithm name, or the
exception that occurred while trying to
+ * calculate it, never {@code null}.
+ * @throws IOException In case of any problem.
+ */
+@Nonnull
+Map calculate(@Nonnull byte[] data, @Nonnull
Collection algorithms)
Review Comment:
The returned Map is not really useful. It should be
Map`
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,87 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a list of {@link ChecksumAlgorithm} in same order as
[jira] [Commented] (MNG-7957) Expose checksum service on API
[
https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799097#comment-17799097
]
ASF GitHub Bot commented on MNG-7957:
-
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1432953322
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,87 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a list of {@link ChecksumAlgorithm} in same order as algorithm
names are ordered, or throws if any of the
+ * algorithm name is not supported. The returned list has equal count of
elements as passed in collection of names,
+ * and if names contains duplicated elements, the returned list of
algorithms will have duplicates as well.
+ *
+ * @throws IllegalArgumentException if any asked algorithm name is not
supported.
+ * @throws NullPointerException if passed in list of names is {@code null}.
+ */
+@Nonnull
+Collection selectList(@Nonnull Collection
algorithmNames);
Review Comment:
the doc and name should be adjusted to the list -> collection change in the
return type
> Expose checksum service on API
> --
>
> Key: MNG-7957
> URL: https://issues.apache.org/jira/browse/MNG-7957
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Resolver since 1.8 has extensible checksum SPI:
> [https://maven.apache.org/resolver/about-checksums.html]
> I think it would be worth to expose that not directly, but via some sort of
> Service in new Maven 4 API?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7957] Checksum API (backed by Resolver) [maven]
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1432953322
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,87 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a list of {@link ChecksumAlgorithm} in same order as algorithm
names are ordered, or throws if any of the
+ * algorithm name is not supported. The returned list has equal count of
elements as passed in collection of names,
+ * and if names contains duplicated elements, the returned list of
algorithms will have duplicates as well.
+ *
+ * @throws IllegalArgumentException if any asked algorithm name is not
supported.
+ * @throws NullPointerException if passed in list of names is {@code null}.
+ */
+@Nonnull
+Collection selectList(@Nonnull Collection
algorithmNames);
Review Comment:
the doc and name should be adjusted to the list -> collection change in the
return type
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7957) Expose checksum service on API
[
https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799096#comment-17799096
]
ASF GitHub Bot commented on MNG-7957:
-
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1432952929
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,87 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a list of {@link ChecksumAlgorithm} in same order as algorithm
names are ordered, or throws if any of the
+ * algorithm name is not supported. The returned list has equal count of
elements as passed in collection of names,
+ * and if names contains duplicated elements, the returned list of
algorithms will have duplicates as well.
+ *
+ * @throws IllegalArgumentException if any asked algorithm name is not
supported.
+ * @throws NullPointerException if passed in list of names is {@code null}.
+ */
+@Nonnull
+Collection selectList(@Nonnull Collection
algorithmNames);
+
+/**
+ * Returns immutable collection of all supported algorithm names.
+ */
+@Nonnull
+Collection getChecksumAlgorithmNames();
+
+/**
+ * Calculates checksums for specified data.
+ *
+ * @param dataThe content for which to calculate checksums, must
not be {@code null}.
+ * @param algorithms The checksum algorithm factories to use, must not be
{@code null}.
+ * @return The calculated checksums, indexed by algorithm name, or the
exception that occurred while trying to
+ * calculate it, never {@code null}.
+ * @throws IOException In case of any problem.
+ */
+@Nonnull
+Map calculate(@Nonnull byte[] data, @Nonnull
Collection algorithms)
+throws IOException;
+
+/**
+ * Calculates checksums for specified file.
+ *
+ * @param fileThe file for which to calculate checksums, must not
be {@code null}.
+ * @param algorithms The checksum algorithm factories to use, must not be
{@code null}.
+ * @return The calculated checksums, indexed by algorithm name, or the
exception that occurred while trying to
+ * calculate it, never {@code null}.
+ * @throws IOException In case of any problem.
+ */
+@Nonnull
+Map calculate(@Nonnull Path file, @Nonnull
Collection algorithms)
Review Comment:
For ease of use ,we're missing `calculate(InputStream,
Collection)` imho.
> Expose checksum service on API
> --
>
> Key: MNG-7957
> URL: https://issues.apache.org/jira/browse/MNG-7957
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Resolver since 1.8 has extensible checksum SPI:
> [https://maven.apache.org/resolver/about-checksums.html]
> I think it would be worth to expose that not directly, but via some sort of
> Service in new Maven 4 API?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7957] Checksum API (backed by Resolver) [maven]
gnodet commented on code in PR #1359:
URL: https://github.com/apache/maven/pull/1359#discussion_r1432952929
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ChecksumAlgorithmService.java:
##
@@ -0,0 +1,87 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.api.services;
+
+import java.io.*;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.Map;
+
+import org.apache.maven.api.Service;
+import org.apache.maven.api.annotations.Experimental;
+import org.apache.maven.api.annotations.Nonnull;
+
+/**
+ * Checksum algorithms service.
+ *
+ * @since 4.0.0
+ */
+@Experimental
+public interface ChecksumAlgorithmService extends Service {
+/**
+ * Returns {@link ChecksumAlgorithm} for given algorithm name, or throws
if algorithm not supported.
+ *
+ * @throws IllegalArgumentException if asked algorithm name is not
supported.
+ */
+@Nonnull
+ChecksumAlgorithm select(@Nonnull String algorithmName);
+
+/**
+ * Returns a list of {@link ChecksumAlgorithm} in same order as algorithm
names are ordered, or throws if any of the
+ * algorithm name is not supported. The returned list has equal count of
elements as passed in collection of names,
+ * and if names contains duplicated elements, the returned list of
algorithms will have duplicates as well.
+ *
+ * @throws IllegalArgumentException if any asked algorithm name is not
supported.
+ * @throws NullPointerException if passed in list of names is {@code null}.
+ */
+@Nonnull
+Collection selectList(@Nonnull Collection
algorithmNames);
+
+/**
+ * Returns immutable collection of all supported algorithm names.
+ */
+@Nonnull
+Collection getChecksumAlgorithmNames();
+
+/**
+ * Calculates checksums for specified data.
+ *
+ * @param dataThe content for which to calculate checksums, must
not be {@code null}.
+ * @param algorithms The checksum algorithm factories to use, must not be
{@code null}.
+ * @return The calculated checksums, indexed by algorithm name, or the
exception that occurred while trying to
+ * calculate it, never {@code null}.
+ * @throws IOException In case of any problem.
+ */
+@Nonnull
+Map calculate(@Nonnull byte[] data, @Nonnull
Collection algorithms)
+throws IOException;
+
+/**
+ * Calculates checksums for specified file.
+ *
+ * @param fileThe file for which to calculate checksums, must not
be {@code null}.
+ * @param algorithms The checksum algorithm factories to use, must not be
{@code null}.
+ * @return The calculated checksums, indexed by algorithm name, or the
exception that occurred while trying to
+ * calculate it, never {@code null}.
+ * @throws IOException In case of any problem.
+ */
+@Nonnull
+Map calculate(@Nonnull Path file, @Nonnull
Collection algorithms)
Review Comment:
For ease of use ,we're missing `calculate(InputStream,
Collection)` imho.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MCOMPILER-567) Fail to compile if the "generated-sources/annotations" does not exist
[
https://issues.apache.org/jira/browse/MCOMPILER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799093#comment-17799093
]
ASF GitHub Bot commented on MCOMPILER-567:
--
jorsol commented on code in PR #218:
URL:
https://github.com/apache/maven-compiler-plugin/pull/218#discussion_r1432938500
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1172,6 +1172,8 @@ public void execute() throws MojoExecutionException,
CompilationFailureException
try (Stream walk =
Files.walk(getGeneratedSourcesDirectory().toPath())) {
walk.sorted(Comparator.reverseOrder()).map(Path::toFile).forEach(File::delete);
+// MCOMPILER-567: recreate directory
+
Files.createDirectories(getGeneratedSourcesDirectory().toPath());
Review Comment:
Done! it should be clear now.
> Fail to compile if the "generated-sources/annotations" does not exist
> -
>
> Key: MCOMPILER-567
> URL: https://issues.apache.org/jira/browse/MCOMPILER-567
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.12.0
>Reporter: Jorge Solórzano
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.12.1
>
>
> On some configurations (like a Kotlin project), the cleanup of the
> generated-soruces/annotations directory returns an error:
> {code:java}
> Caused by: java.lang.IllegalStateException: basedir
> /maven-compiler-plugin/target/it/MCOMPILER-XX/target/generated-sources/annotations
> does not exist
> at org.codehaus.plexus.util.DirectoryScanner.scan
> (DirectoryScanner.java:268)
> at
> org.codehaus.plexus.compiler.AbstractCompiler.getSourceFilesForSourceRoot
> (AbstractCompiler.java:168)
> at org.codehaus.plexus.compiler.AbstractCompiler.getSourceFiles
> (AbstractCompiler.java:194)
> at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile
> (JavacCompiler.java:138)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:1187)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:212)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348){code}
>
> I didn't catch this earlier since I don't use Kotlin and on a normal project,
> this should not be an issue since the javac documentation mentions that the
> directory, and any necessary subdirectories, will be created if
Re: [PR] [MCOMPILER-567] - Fail to compile if the generated-sources/annotation… [maven-compiler-plugin]
jorsol commented on code in PR #218:
URL:
https://github.com/apache/maven-compiler-plugin/pull/218#discussion_r1432938500
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1172,6 +1172,8 @@ public void execute() throws MojoExecutionException,
CompilationFailureException
try (Stream walk =
Files.walk(getGeneratedSourcesDirectory().toPath())) {
walk.sorted(Comparator.reverseOrder()).map(Path::toFile).forEach(File::delete);
+// MCOMPILER-567: recreate directory
+
Files.createDirectories(getGeneratedSourcesDirectory().toPath());
Review Comment:
Done! it should be clear now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7957) Expose checksum service on API
[ https://issues.apache.org/jira/browse/MNG-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799090#comment-17799090 ] ASF GitHub Bot commented on MNG-7957: - cstamas opened a new pull request, #1359: URL: https://github.com/apache/maven/pull/1359 Expose checksumming API (backed by Resolver). --- https://issues.apache.org/jira/browse/MNG-7957 > Expose checksum service on API > -- > > Key: MNG-7957 > URL: https://issues.apache.org/jira/browse/MNG-7957 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.x-candidate > > > Resolver since 1.8 has extensible checksum SPI: > [https://maven.apache.org/resolver/about-checksums.html] > I think it would be worth to expose that not directly, but via some sort of > Service in new Maven 4 API? -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MARCHETYPES-76] maven-archetype-quickstart generates EOLed maven.compiler setup [maven-archetypes]
judovana commented on code in PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#discussion_r1432919700 ## maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml: ## @@ -1,11 +1,11 @@ -#macro( compilerProperties $javaCompilerVersion ) +#macro( compilerProperties $jcv ) Review Comment: There was the name clash between global and local variable. I wanted to make clear, that it is obvious on first glance, what is local to macro, and what is global one. See https://github.com/apache/maven-archetypes/blob/master/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L2 compare with full: https://github.com/judovana/maven-archetypes/blob/defaultJdk8/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L48 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MARCHETYPES-76) maven-archetype-quickstart generates EOLed maven.compiler setup
[ https://issues.apache.org/jira/browse/MARCHETYPES-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799087#comment-17799087 ] ASF GitHub Bot commented on MARCHETYPES-76: --- judovana commented on code in PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#discussion_r1432919700 ## maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml: ## @@ -1,11 +1,11 @@ -#macro( compilerProperties $javaCompilerVersion ) +#macro( compilerProperties $jcv ) Review Comment: There was the name clash between global and local variable. I wanted to make clear, that it is obvious on first glance, what is local to macro, and what is global one. See https://github.com/apache/maven-archetypes/blob/master/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L2 compare with full: https://github.com/judovana/maven-archetypes/blob/defaultJdk8/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L48 > maven-archetype-quickstart generates EOLed maven.compiler setup > > > Key: MARCHETYPES-76 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-76 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The default imput to #compilerProperties is 1.7, which is making any > generated project to be not buildable with fresh jdk21. The default should > be1.8. Where jdk8 is still live and jdk21 is still comaptible with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MARCHETYPES-76) maven-archetype-quickstart generates EOLed maven.compiler setup
[ https://issues.apache.org/jira/browse/MARCHETYPES-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799088#comment-17799088 ] ASF GitHub Bot commented on MARCHETYPES-76: --- judovana commented on code in PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#discussion_r1432919700 ## maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml: ## @@ -1,11 +1,11 @@ -#macro( compilerProperties $javaCompilerVersion ) +#macro( compilerProperties $jcv ) Review Comment: There was the name clash between global and local "variable". I wanted to make clear, that it is obvious on first glance, what is local to macro, and what is global one. See https://github.com/apache/maven-archetypes/blob/master/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L2 compare with full: https://github.com/judovana/maven-archetypes/blob/defaultJdk8/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L48 > maven-archetype-quickstart generates EOLed maven.compiler setup > > > Key: MARCHETYPES-76 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-76 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The default imput to #compilerProperties is 1.7, which is making any > generated project to be not buildable with fresh jdk21. The default should > be1.8. Where jdk8 is still live and jdk21 is still comaptible with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MARCHETYPES-76] maven-archetype-quickstart generates EOLed maven.compiler setup [maven-archetypes]
judovana commented on code in PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#discussion_r1432919700 ## maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml: ## @@ -1,11 +1,11 @@ -#macro( compilerProperties $javaCompilerVersion ) +#macro( compilerProperties $jcv ) Review Comment: There was the name clash between global and local "variable". I wanted to make clear, that it is obvious on first glance, what is local to macro, and what is global one. See https://github.com/apache/maven-archetypes/blob/master/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L2 compare with full: https://github.com/judovana/maven-archetypes/blob/defaultJdk8/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L48 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MARCHETYPES-76) maven-archetype-quickstart generates EOLed maven.compiler setup
[ https://issues.apache.org/jira/browse/MARCHETYPES-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799086#comment-17799086 ] ASF GitHub Bot commented on MARCHETYPES-76: --- judovana commented on code in PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#discussion_r1432919700 ## maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml: ## @@ -1,11 +1,11 @@ -#macro( compilerProperties $javaCompilerVersion ) +#macro( compilerProperties $jcv ) Review Comment: There was the name clash between global and local variable. wanted to make clear, that it is obvious on first glance, what is local to macro, and what is global one. See https://github.com/apache/maven-archetypes/blob/master/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L2 compare with full: https://github.com/judovana/maven-archetypes/blob/defaultJdk8/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L48 > maven-archetype-quickstart generates EOLed maven.compiler setup > > > Key: MARCHETYPES-76 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-76 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The default imput to #compilerProperties is 1.7, which is making any > generated project to be not buildable with fresh jdk21. The default should > be1.8. Where jdk8 is still live and jdk21 is still comaptible with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MARCHETYPES-76] maven-archetype-quickstart generates EOLed maven.compiler setup [maven-archetypes]
judovana commented on code in PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#discussion_r1432919700 ## maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml: ## @@ -1,11 +1,11 @@ -#macro( compilerProperties $javaCompilerVersion ) +#macro( compilerProperties $jcv ) Review Comment: There was the name clash between global and local variable. wanted to make clear, that it is obvious on first glance, what is local to macro, and what is global one. See https://github.com/apache/maven-archetypes/blob/master/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L2 compare with full: https://github.com/judovana/maven-archetypes/blob/defaultJdk8/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L48 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Disable MNG-1088 test for MNG-7977 [maven-integration-testing]
gnodet opened a new pull request, #329: URL: https://github.com/apache/maven-integration-testing/pull/329 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MARCHETYPES-76) maven-archetype-quickstart generates EOLed maven.compiler setup
[ https://issues.apache.org/jira/browse/MARCHETYPES-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799072#comment-17799072 ] ASF GitHub Bot commented on MARCHETYPES-76: --- gnodet commented on code in PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#discussion_r1432878450 ## maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml: ## @@ -1,11 +1,11 @@ -#macro( compilerProperties $javaCompilerVersion ) +#macro( compilerProperties $jcv ) Review Comment: Any reason why this variable has been renamed ? `javaCompilerVersion` seems quite easy to understand... > maven-archetype-quickstart generates EOLed maven.compiler setup > > > Key: MARCHETYPES-76 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-76 > Project: Maven Archetype Bundles > Issue Type: Bug >Reporter: jiri vanek >Priority: Major > > The default imput to #compilerProperties is 1.7, which is making any > generated project to be not buildable with fresh jdk21. The default should > be1.8. Where jdk8 is still live and jdk21 is still comaptible with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MARCHETYPES-76] maven-archetype-quickstart generates EOLed maven.compiler setup [maven-archetypes]
gnodet commented on code in PR #18: URL: https://github.com/apache/maven-archetypes/pull/18#discussion_r1432878450 ## maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml: ## @@ -1,11 +1,11 @@ -#macro( compilerProperties $javaCompilerVersion ) +#macro( compilerProperties $jcv ) Review Comment: Any reason why this variable has been renamed ? `javaCompilerVersion` seems quite easy to understand... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7982) Switch to enable transitivity in depMgr used by Maven
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7982: - Description: As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are calling out how depMgt should be handled in both cases: when building (it is), and when consuming (it is not). Resolver MRESOLVER-462 that is a boolean switch (to enable or disable -- as before -- the transitivity in depMgr). This depends on resolver release. was: As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are calling out how depMgt should be handled in both cases: when building (it is), and when consuming (it is not). As it turned out, Maven3 since existence of Resolver used the "classic" depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to apply "transitive" depMgr as default, while offer fallback to classic? This depends on resolver release. > Switch to enable transitivity in depMgr used by Maven > - > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > Resolver MRESOLVER-462 that is a boolean switch (to enable or disable -- as > before -- the transitivity in depMgr). > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7982) Switch to enable transitivity in depMgr used by Maven
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7982: - Summary: Switch to enable transitivity in depMgr used by Maven (was: Make classic transitive depMgr the default, provide fallback to classic and transitive) > Switch to enable transitivity in depMgr used by Maven > - > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7983) Update to Slf4j 2.x
[ https://issues.apache.org/jira/browse/MNG-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799040#comment-17799040 ] ASF GitHub Bot commented on MNG-7983: - gnodet opened a new pull request, #1358: URL: https://github.com/apache/maven/pull/1358 JIRA issue: [MNG-7983](https://issues.apache.org/jira/browse/MNG-7983) > Update to Slf4j 2.x > --- > > Key: MNG-7983 > URL: https://issues.apache.org/jira/browse/MNG-7983 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7983) Update to Slf4j 2.x
[ https://issues.apache.org/jira/browse/MNG-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-7983: Assignee: Guillaume Nodet > Update to Slf4j 2.x > --- > > Key: MNG-7983 > URL: https://issues.apache.org/jira/browse/MNG-7983 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864547699 ITs look good. And thinking more about this, this should be maybe just a boolean flag? `classic(transitive)`? As I would leave out completely the "transitive" and the "default" as they do introduce unwanted behaviour for sure (fail ITs), rendering existing working build possibly broken. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799031#comment-17799031 ] ASF GitHub Bot commented on MNG-7982: - cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864547699 ITs look good. And thinking more about this, this should be maybe just a boolean flag? `classic(transitive)`? As I would leave out completely the "transitive" and the "default" as they do introduce unwanted behaviour for sure (fail ITs), rendering existing working build possibly broken. > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MENFORCER-495) Invalid use of JAVA_HOME environment variable
Michael Osipov created MENFORCER-495:
Summary: Invalid use of JAVA_HOME environment variable
Key: MENFORCER-495
URL: https://issues.apache.org/jira/browse/MENFORCER-495
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: requireJavaVendor, requireJavaVersion
Affects Versions: 3.4.1
Reporter: Michael Osipov
I have received the following on Maven master:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.4.1:enforce
(enforce-bytecode-version) on project maven:
[ERROR] Rule 0: org.apache.maven.enforcer.rules.version.RequireJavaVersion
failed with message:
[ERROR] Detected JDK version 1.8.0-392 (JAVA_HOME=/usr/local/openjdk8/jre) is
not in the allowed range [11,).
{noformat}
I have never set {{JAVA_HOME}}. That is confusing. {{JAVA_HOME}} is not the
same as {{java.home}}.
Affected spots:
https://github.com/search?q=repo%3Aapache%2Fmaven-enforcer%20java_home=code
It should likely just print the value...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799010#comment-17799010 ] ASF GitHub Bot commented on MNG-7982: - cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864470425 I see no difference to what happens if you use two libs that declare different version on some artifact, really. And depMgt (_unlike BOM imports_) let it all to you to sort it out in "maven way". > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864470425 I see no difference to what happens if you use two libs that declare different version on some artifact, really. And depMgt (_unlike BOM imports_) let it all to you to sort it out in "maven way". -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799009#comment-17799009 ] ASF GitHub Bot commented on MNG-7982: - rmannibucau commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864468358 @cstamas right, now consider 2 lib authors for your project (3rd maven build to make it clear) and also maven 3 consumers (let's ignore 2, agree), it becomes a mess for us :( > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
rmannibucau commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864468358 @cstamas right, now consider 2 lib authors for your project (3rd maven build to make it clear) and also maven 3 consumers (let's ignore 2, agree), it becomes a mess for us :( -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799006#comment-17799006 ] ASF GitHub Bot commented on MNG-7982: - cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864465206 IMO, this change > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864465206 IMO, this change -- if goes in -- will just make POMs _simpler_ and not _more complex_. Essentially what this makes possible is that lib author (whos lib is used somewhere deep in your project) pass information to your project, instead to have those information neglected. Hence, your POM will need _less_ and not _more_ depMgt entries. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799004#comment-17799004 ] ASF GitHub Bot commented on MNG-7982: - rmannibucau commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864461670 @cstamas I understand that and ultimately I hope we reach your proposal I do like, but I don't want to be at the cost of making builds more complex and user most lost, this is how I end on the "strict" mode for depMgt in maven 4 but I'm not 100% happy with that so any idea welcomed ;). > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
rmannibucau commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864461670 @cstamas I understand that and ultimately I hope we reach your proposal I do like, but I don't want to be at the cost of making builds more complex and user most lost, this is how I end on the "strict" mode for depMgt in maven 4 but I'm not 100% happy with that so any idea welcomed ;). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799003#comment-17799003 ] ASF GitHub Bot commented on MNG-7982: - cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864458580 And as regarding "blowing", lets see what ITs has to say. Also we could maybe add IT for https://issues.apache.org/jira/browse/MRESOLVER-235 > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864458580 And as regarding "blowing", lets see what ITs has to say. Also we could maybe add IT for https://issues.apache.org/jira/browse/MRESOLVER-235 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799002#comment-17799002 ] ASF GitHub Bot commented on MNG-7982: - cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864456808 This setting cannot be per dependency, at least resolver does not support that. The depMgr is set per session. And what current PR changes is really only this: are depMgt sections obeyed only 2 level deep or to the end of pit. The "2 level depth" comes from Maven2 times, and was artificial limit just to make Maven3 (resolver in it) work like Maven2 did. Unsure why Maven4 would need to work in this respect as Maven2 did. > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864456808 This setting cannot be per dependency, at least resolver does not support that. The depMgr is set per session. And what current PR changes is really only this: are depMgt sections obeyed only 2 level deep or to the end of pit. The "2 level depth" comes from Maven2 times, and was artificial limit just to make Maven3 (resolver in it) work like Maven2 did. Unsure why Maven4 would need to work in this respect as Maven2 did. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799000#comment-17799000 ] ASF GitHub Bot commented on MNG-7982: - rmannibucau commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864449457 What I worry about it is the fact we are moving the current issues a step further but I don't understand yet how it does fix anything, this kind of configuration looks per dependency, so while I fully agree we can make it global or per version, it will keep blowing up as soon as you have > 2 dep there no? Don't get me wrong, I think the transitive feature is rather a good thing if we can instantiate it without more side effects than we have today but alone it looks like mixing behaviors which all have pitfalls and therefore just make it more complex. Ultimately it can mean we become stricter on the depMgt and forbid not resolved conflicts (a bit like what enforcer plugin enables), this way the resolution of a built project (not transitive deps alone) is always deterministic at a little user cost. Still thinking out loud to try to get this feature onboard without realizing in some months we are back where we were in terms of issues with new ones due to the behavior change and "resolution merge" logic we would need from consumed poms. > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
rmannibucau commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864449457 What I worry about it is the fact we are moving the current issues a step further but I don't understand yet how it does fix anything, this kind of configuration looks per dependency, so while I fully agree we can make it global or per version, it will keep blowing up as soon as you have > 2 dep there no? Don't get me wrong, I think the transitive feature is rather a good thing if we can instantiate it without more side effects than we have today but alone it looks like mixing behaviors which all have pitfalls and therefore just make it more complex. Ultimately it can mean we become stricter on the depMgt and forbid not resolved conflicts (a bit like what enforcer plugin enables), this way the resolution of a built project (not transitive deps alone) is always deterministic at a little user cost. Still thinking out loud to try to get this feature onboard without realizing in some months we are back where we were in terms of issues with new ones due to the behavior change and "resolution merge" logic we would need from consumed poms. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798998#comment-17798998 ] ASF GitHub Bot commented on MNG-7982: - gnodet commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864442381 > Hi @cstamas , what is the plan to identify mvn 4 consumed artifacts to switch the impl, using the mvn4 specific pom metadata file? in current state it breaks probably too easily IMHO and I didn't find how we enable this behavior in the produced pom for the consumed artifact - I don't think it is good to be a config prop, it should belong to the pom only to avoid a global toggle which will work only under a closed ecosystem. The consumer has no knowledge. I also kinda saw that as a problem... I wonder if this should be automatically toggled by the modelVersion of the root project: if using a 4.1.0 model, then use the new depMgr, if using 4.0.0 model, use the Maven 3 compatible one This piece can be easily detected very early at boot time and could be used to configure the resolver. > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
gnodet commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864442381 > Hi @cstamas , what is the plan to identify mvn 4 consumed artifacts to switch the impl, using the mvn4 specific pom metadata file? in current state it breaks probably too easily IMHO and I didn't find how we enable this behavior in the produced pom for the consumed artifact - I don't think it is good to be a config prop, it should belong to the pom only to avoid a global toggle which will work only under a closed ecosystem. The consumer has no knowledge. I also kinda saw that as a problem... I wonder if this should be automatically toggled by the modelVersion of the root project: if using a 4.1.0 model, then use the new depMgr, if using 4.0.0 model, use the Maven 3 compatible one This piece can be easily detected very early at boot time and could be used to configure the resolver. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7980) Add ability to ignore transitive dependency repositories
[ https://issues.apache.org/jira/browse/MNG-7980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798996#comment-17798996 ] ASF GitHub Bot commented on MNG-7980: - cstamas merged PR #1354: URL: https://github.com/apache/maven/pull/1354 > Add ability to ignore transitive dependency repositories > > > Key: MNG-7980 > URL: https://issues.apache.org/jira/browse/MNG-7980 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > > In certain cases it is valid to ignore repositories introduced by transitive > dependencies. They are usually needed, but in certain cases (ie. air gapped > environment) they are just causing problems. Even if environment, or the POM > itself defines all the repositories needed for the build (so the "superset" > of remote repositories that have all the artifacts the build even needs), > this requires tuning in case of dependency changes, as new and new > repositories may be introduced as dependencies change. > Ideally, Maven could be instructed to globally ignore any repository > introduced by dependency, as POM itself has it call (in controlled fashion) > to fulfil all the artifacts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7980) Add ability to ignore transitive dependency repositories
[ https://issues.apache.org/jira/browse/MNG-7980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-7980. Resolution: Fixed > Add ability to ignore transitive dependency repositories > > > Key: MNG-7980 > URL: https://issues.apache.org/jira/browse/MNG-7980 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > > In certain cases it is valid to ignore repositories introduced by transitive > dependencies. They are usually needed, but in certain cases (ie. air gapped > environment) they are just causing problems. Even if environment, or the POM > itself defines all the repositories needed for the build (so the "superset" > of remote repositories that have all the artifacts the build even needs), > this requires tuning in case of dependency changes, as new and new > repositories may be introduced as dependencies change. > Ideally, Maven could be instructed to globally ignore any repository > introduced by dependency, as POM itself has it call (in controlled fashion) > to fulfil all the artifacts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7978] Decouple maven-artifact from maven-resolver-provider [maven]
cstamas merged PR #1352: URL: https://github.com/apache/maven/pull/1352 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7978) Decouple maven-artifact from maven-resolver-provider
[ https://issues.apache.org/jira/browse/MNG-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798995#comment-17798995 ] ASF GitHub Bot commented on MNG-7978: - cstamas merged PR #1352: URL: https://github.com/apache/maven/pull/1352 > Decouple maven-artifact from maven-resolver-provider > > > Key: MNG-7978 > URL: https://issues.apache.org/jira/browse/MNG-7978 > Project: Maven > Issue Type: Task > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > > As it is actually not needed there. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7980] CLI switch to ignore transitive repositories. [maven]
cstamas merged PR #1354: URL: https://github.com/apache/maven/pull/1354 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7978) Decouple maven-artifact from maven-resolver-provider
[ https://issues.apache.org/jira/browse/MNG-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-7978. Resolution: Fixed > Decouple maven-artifact from maven-resolver-provider > > > Key: MNG-7978 > URL: https://issues.apache.org/jira/browse/MNG-7978 > Project: Maven > Issue Type: Task > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > > As it is actually not needed there. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7982] Make classicTransitive the default depMgr [maven]
cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864436787 @rmannibucau this PR is draft on purpose. Actually, I'd say "consider all resolver related Maven PRs draft" I do, as am just throwing ideas or missing Maven features, to improve use of (so far unused or newly made) Resolver features in Maven, but HOW are they gonna be consumed/integrated into Maven I'd leave to @gnodet and probably you :smile: This PR would fix for example these issues, reported by many, while providing "escape hatch" to go back to "classic" if needed: https://issues.apache.org/jira/browse/MRESOLVER-235 https://issues.apache.org/jira/browse/MNG-7003 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798993#comment-17798993 ] ASF GitHub Bot commented on MNG-7982: - cstamas commented on PR #1357: URL: https://github.com/apache/maven/pull/1357#issuecomment-1864436787 @rmannibucau this PR is draft on purpose. Actually, I'd say "consider all resolver related Maven PRs draft" I do, as am just throwing ideas or missing Maven features, to improve use of (so far unused or newly made) Resolver features in Maven, but HOW are they gonna be consumed/integrated into Maven I'd leave to @gnodet and probably you :smile: This PR would fix for example these issues, reported by many, while providing "escape hatch" to go back to "classic" if needed: https://issues.apache.org/jira/browse/MRESOLVER-235 https://issues.apache.org/jira/browse/MNG-7003 > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7982: - Component/s: Artifacts and Repositories (was: Core) > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7960) Artifact collection filtering
[
https://issues.apache.org/jira/browse/MNG-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7960:
-
Description:
Exposed work from MRESOLVER-451 and MRESOLVER-460: allow for various filterings.
User should be able to "tune" range processing. Also, as this affects
resolution, ideally these "tuned" parameters should be stored along project,
especially if project relies on these (ie. in {{.mvn/maven.config}}).
Explanation: Maven is notoriously "bad" when ranges are being used. Hence, this
issue introduces (range) version filtering support. The configuration accepts
an "expression" (CSV) of filters. Supported filters are:
* "h" (equivalent of "h(1)") or "h(N)" - that selects "top N" versions from
range
* "l" (equivalent of "l(1)") or "l(N)" - that selects "bottom N" versions from
range
* "s" snapshot filter: if root/project is snapshot, will allow snapshots in
ranges, otherwise snapshot versions are filtered out (also see Resolver config
{{aether.snapshotFilter}} present in Resolver 1.x but has no effect in Maven3
as it is not used).
* "e(G:A:V)" exclusion, if range for G:A is processed, V is _excluded_ from
range. V can be version range as well, then whole range is excluded.
The built expressions are evaluated in-order, and filtering effect is
accumulated. Hence, expression like "h(5),l" will return 5th highest version,
etc.
This depends on resolver release.
was:
Exposed work from MRESOLVER-451 and MRESOLVER-460: allow for various filterings.
User should be able to "tune" range processing. Also, as this affects
resolution, ideally these "tuned" parameters should be stored along project,
especially if project relies on these (ie. in {{.mvn/maven.config}}).
Explanation: Maven is notoriously "bad" when ranges are being used. Hence, this
issue introduces (range) version filtering support. The configuration accepts
an "expression" (CSV) of filters. Supported filters are:
* "h" (equivalent of "h(1)") or "h(N)" - that selects "top N" versions from
range
* "l" (equivalent of "l(1)") or "l(N)" - that selects "bottom N" versions from
range
* "s" snapshot filter: if root/project is snapshot, will allow snapshots in
ranges, otherwise snapshot versions are filtered out (also see Resolver config
{{aether.snapshotFilter}} present in Resolver 1.x but has no effect in Maven3
as it is not used).
* "e(G:A:V)" exclusion, if range for G:A is processed, V is _excluded_ from
range. V can be version range as well, then whole range is excluded.
The built expressions are evaluated in-order, and filtering effect is
accumulated. Hence, expression like "h(5),l" will return 5th highest version,
etc.
> Artifact collection filtering
> -
>
> Key: MNG-7960
> URL: https://issues.apache.org/jira/browse/MNG-7960
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-12
>
>
> Exposed work from MRESOLVER-451 and MRESOLVER-460: allow for various
> filterings.
> User should be able to "tune" range processing. Also, as this affects
> resolution, ideally these "tuned" parameters should be stored along project,
> especially if project relies on these (ie. in {{.mvn/maven.config}}).
> Explanation: Maven is notoriously "bad" when ranges are being used. Hence,
> this issue introduces (range) version filtering support. The configuration
> accepts an "expression" (CSV) of filters. Supported filters are:
> * "h" (equivalent of "h(1)") or "h(N)" - that selects "top N" versions from
> range
> * "l" (equivalent of "l(1)") or "l(N)" - that selects "bottom N" versions
> from range
> * "s" snapshot filter: if root/project is snapshot, will allow snapshots in
> ranges, otherwise snapshot versions are filtered out (also see Resolver
> config {{aether.snapshotFilter}} present in Resolver 1.x but has no effect in
> Maven3 as it is not used).
> * "e(G:A:V)" exclusion, if range for G:A is processed, V is _excluded_ from
> range. V can be version range as well, then whole range is excluded.
> The built expressions are evaluated in-order, and filtering effect is
> accumulated. Hence, expression like "h(5),l" will return 5th highest version,
> etc.
> This depends on resolver release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7982: - Description: As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are calling out how depMgt should be handled in both cases: when building (it is), and when consuming (it is not). As it turned out, Maven3 since existence of Resolver used the "classic" depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to apply "transitive" depMgr as default, while offer fallback to classic? This depends on resolver release. was: As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are calling out how depMgt should be handled in both cases: when building (it is), and when consuming (it is not). As it turned out, Maven3 since existence of Resolver used the "classic" depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to apply "transitive" depMgr as default, while offer fallback to classic? > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? > This depends on resolver release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7982: - Fix Version/s: 4.0.0-alpha-12 (was: 4.0.0-alpha-11) > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-12 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7982) Make classic transitive depMgr the default, provide fallback to classic and transitive
[ https://issues.apache.org/jira/browse/MNG-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7982: - Summary: Make classic transitive depMgr the default, provide fallback to classic and transitive (was: Make transitive depMgr the default, provide fallback to classic) > Make classic transitive depMgr the default, provide fallback to classic and > transitive > -- > > Key: MNG-7982 > URL: https://issues.apache.org/jira/browse/MNG-7982 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > > As seen in various issues (MRESOLVER-235, MNG-7003 and others), users are > calling out how depMgt should be handled in both cases: when building (it > is), and when consuming (it is not). > As it turned out, Maven3 since existence of Resolver used the "classic" > depMgr that works like Maven2 (does not apply depMgt). Maven4 may be point to > apply "transitive" depMgr as default, while offer fallback to classic? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-462) Introduce transitive classic depMgr as well
[
https://issues.apache.org/jira/browse/MRESOLVER-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-462:
--
Fix Version/s: 2.0.0
> Introduce transitive classic depMgr as well
> ---
>
> Key: MRESOLVER-462
> URL: https://issues.apache.org/jira/browse/MRESOLVER-462
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-6
>
>
> As there are some subtle differences along the lines, not only deriveUntil
> and applyFrom.
> "transitive classic" should have just {{deriveUntil=Integer.MAX_VALUE}}
> instead as plain classic have {{deriveUntil=2}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-462) Introduce transitive classic depMgr as well
[
https://issues.apache.org/jira/browse/MRESOLVER-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-462.
-
Assignee: Tamas Cservenak
Resolution: Fixed
> Introduce transitive classic depMgr as well
> ---
>
> Key: MRESOLVER-462
> URL: https://issues.apache.org/jira/browse/MRESOLVER-462
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0-alpha-6
>
>
> As there are some subtle differences along the lines, not only deriveUntil
> and applyFrom.
> "transitive classic" should have just {{deriveUntil=Integer.MAX_VALUE}}
> instead as plain classic have {{deriveUntil=2}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-462) Introduce transitive classic depMgr as well
[
https://issues.apache.org/jira/browse/MRESOLVER-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798983#comment-17798983
]
ASF GitHub Bot commented on MRESOLVER-462:
--
cstamas merged PR #403:
URL: https://github.com/apache/maven-resolver/pull/403
> Introduce transitive classic depMgr as well
> ---
>
> Key: MRESOLVER-462
> URL: https://issues.apache.org/jira/browse/MRESOLVER-462
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0-alpha-6
>
>
> As there are some subtle differences along the lines, not only deriveUntil
> and applyFrom.
> "transitive classic" should have just {{deriveUntil=Integer.MAX_VALUE}}
> instead as plain classic have {{deriveUntil=2}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-462] Classic Transitive depMgr [maven-resolver]
cstamas merged PR #403: URL: https://github.com/apache/maven-resolver/pull/403 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
