maven clean install with Postgres 13 on Mac M1 chip failing at step PL/Java Native Code
Hello Team, I cannot install maven (with command) 'mvn clean install' on Mac m1 as it fails at step PL/Java backend native code. (build trace below) However, I tried with 11,12(failed with a similar error). The build is successful only with Postgres 14. I required earlier versions of Postgres (either 11,12 or 13) for my requirement. ld: warning: ld: warning: ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/Timestamp.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/Function.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64 ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/SPI.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64ld: warning: ld: warning: ld: warning: ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/SQLOutputToTuple.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/VarlenaWrapper.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/Boolean.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64 ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/UDT.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64ld: warning: ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/Exception.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64 ld: warning: ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/InstallHelper.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64 ld: warning: ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/Any.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64 ld: warning: ld: warning: ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/JNICalls.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64 ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/String.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64 ld: warning: ignoring file /Users/kishorebiradavolu/pljava/pljava-so/target/pljava-pgxs/SQLInputFromTuple.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64 ld: can't link with a main executable file '/Library/PostgreSQL/13/bin/postgres' for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) [INFO] [INFO] Reactor Summary for PostgreSQL PL/Java 2-SNAPSHOT: [INFO] [INFO] PostgreSQL PL/Java . SUCCESS [ 0.514 s] [INFO] PL/Java API SUCCESS [ 1.997 s] [INFO] PL/Java backend Java code .. SUCCESS [ 1.640 s] [INFO] PL/Java PGXS ... SUCCESS [ 1.615 s] [INFO] PL/Java backend native code FAILURE [ 2.972 s] [INFO] PL/Java Ant tasks .. SKIPPED [INFO] PL/Java examples ... SKIPPED [INFO] PL/Java packaging .. SKIPPED [INFO] [INFO] BUILD FAILURE
[jira] [Commented] (MEAR-309) Support JakartaEE 10
[
https://issues.apache.org/jira/browse/MEAR-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608899#comment-17608899
]
Wolfgang Knauf commented on MEAR-309:
-
Pull request sent. The change was rather trivial - I could copy the code from
the JakartaEE change.
Now please accept it and do a release of the plugin so that the WildFly
archetype is ready when WildFly 27 is released ;).
> Support JakartaEE 10
>
>
> Key: MEAR-309
> URL: https://issues.apache.org/jira/browse/MEAR-309
> Project: Maven EAR Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.0
>Reporter: Wolfgang Knauf
>Priority: Major
>
> Please add support for JakartaEE 10, so that a valid "application.xml" can be
> created.
> As WildFly 27 defaults to JakartaEE 10, I am in the process of updating the
> archetype for a blank WildFly EAR project. And to keep it clean, I want the
> maven-ear-plugin to create a JakartaEE 10 "application.xml" instead of the
> JavaEE8 version.
>
> In the moment, I think I will switch off generating this file
> ("false") in order to avoid
> confusion.
>
> I see that [https://issues.apache.org/jira/projects/MEAR/issues/MEAR-302]
> already added support for JakartaEE9, so I could even try to send a similar
> pull request for 10.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-ear-plugin] WolfgangHG opened a new pull request, #61: [MEAR-309] Support JakartaEE10
WolfgangHG opened a new pull request, #61: URL: https://github.com/apache/maven-ear-plugin/pull/61 Added support for JakartaEE10 (based on the previous commit for JakartaEE9). Issue: [https://issues.apache.org/jira/browse/MEAR-309](https://issues.apache.org/jira/browse/MEAR-309) -- 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
[GitHub] [maven-release] olamy commented on a diff in pull request #151: [MRELEASE-1104] fix stage goal when having both arguments and stagingRepository
olamy commented on code in PR #151: URL: https://github.com/apache/maven-release/pull/151#discussion_r979009677 ## maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/ForkedMavenExecutor.java: ## @@ -110,6 +110,9 @@ public void executeGoals( File workingDirectory, List goals, ReleaseEnvi cl.setWorkingDirectory( workingDirectory.getAbsolutePath() ); +// FIX for MRELEASE-1105 +//cl.addEnvironment( "MAVEN_DEBUG_OPTS", "" ); + Review Comment: That's why it's here as comment. To remember where change that. As I will probably work on next PR in 1 or 2 week so I can definitely forget 🤣 or someone else pick the other issue.. I do not see this as a problem it's a comment and probably helpful one 😉 -- 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
[GitHub] [maven-dependency-plugin] dependabot[bot] commented on pull request #252: Bump slf4j-simple from 1.7.36 to 2.0.2
dependabot[bot] commented on PR #252: URL: https://github.com/apache/maven-dependency-plugin/pull/252#issuecomment-1256426056 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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
[GitHub] [maven-dependency-plugin] slawekjaranowski closed pull request #252: Bump slf4j-simple from 1.7.36 to 2.0.2
slawekjaranowski closed pull request #252: Bump slf4j-simple from 1.7.36 to 2.0.2 URL: https://github.com/apache/maven-dependency-plugin/pull/252 -- 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] (MINVOKER-310) Upgrade Parent to 37
[ https://issues.apache.org/jira/browse/MINVOKER-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608835#comment-17608835 ] Hudson commented on MINVOKER-310: - Build succeeded in Jenkins: Maven » Maven TLP » maven-invoker-plugin » master #49 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-invoker-plugin/job/master/49/ > Upgrade Parent to 37 > > > Key: MINVOKER-310 > URL: https://issues.apache.org/jira/browse/MINVOKER-310 > Project: Maven Invoker Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-release] dependabot[bot] commented on pull request #150: Bump slf4jVersion from 1.7.36 to 2.0.1
dependabot[bot] commented on PR #150: URL: https://github.com/apache/maven-release/pull/150#issuecomment-1256399947 OK, I won't notify you again about this release, but will get in touch when a new version is available. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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
[GitHub] [maven-release] slawekjaranowski closed pull request #150: Bump slf4jVersion from 1.7.36 to 2.0.1
slawekjaranowski closed pull request #150: Bump slf4jVersion from 1.7.36 to 2.0.1 URL: https://github.com/apache/maven-release/pull/150 -- 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
[GitHub] [maven-release] slawekjaranowski commented on a diff in pull request #151: [MRELEASE-1104] fix stage goal when having both arguments and stagingRepository
slawekjaranowski commented on code in PR #151: URL: https://github.com/apache/maven-release/pull/151#discussion_r978837435 ## maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/ForkedMavenExecutor.java: ## @@ -110,6 +110,9 @@ public void executeGoals( File workingDirectory, List goals, ReleaseEnvi cl.setWorkingDirectory( workingDirectory.getAbsolutePath() ); +// FIX for MRELEASE-1105 +//cl.addEnvironment( "MAVEN_DEBUG_OPTS", "" ); + Review Comment: probably for next PR - unneeded comments ## maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/InvokerMavenExecutor.java: ## @@ -72,6 +72,8 @@ public void executeGoals( File workingDirectory, List goals, ReleaseEnvi InvocationRequest req = new DefaultInvocationRequest() .setDebug( getLogger().isDebugEnabled() ) .setBaseDirectory( workingDirectory ) +// fix for MRELEASE-1105 +//.addShellEnvironment( "MAVEN_DEBUG_OPTS", "" ) Review Comment: probably for next PR - unneeded comments -- 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] (MPMD-335) PMD 3.15.0 and 3.16.0 do not use project repository
[
https://issues.apache.org/jira/browse/MPMD-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608829#comment-17608829
]
Naveen Kasthuri commented on MPMD-335:
--
My setup:
* multi-module maven project where PMD is configured at the parent pom.
* PMD 3.15, 3.16, or 3.17.
* the artifact it fails to fetch is in a private artifactory
* Aggregate attribute (or its equivalent target, depending on the version
since the aggregate attribute is deprecated) is used.
* Upon attempting to fetch the dependency, I receive a
DependencyResolutionException. Note that all other plugins, the build, and
earlier versions of PMD work so this isn't a misconfiguration of the repository
settings.
The workaround is to use PMD 3.14.0.
It should be easy to set up a reproducer to mimic this, but since the
reproducer requires a private repository (or at least a non-default
repository), it will be easier for you to set it up than doing asset transfers
from me. Hopefully this helps.
> PMD 3.15.0 and 3.16.0 do not use project repository
> ---
>
> Key: MPMD-335
> URL: https://issues.apache.org/jira/browse/MPMD-335
> Project: Maven PMD Plugin
> Issue Type: Bug
>Reporter: Andre Kalamandeen
>Priority: Major
>
> I've tried to upgrade PMD to 3.16.0 and noticed that when building it tries
> to get artifacts from the default maven repository instead of the repository
> configured in the project.
> This causes issues with the build as certain artifacts are only available in
> the custom repository.
>
> The build error:
> {code:java}
> Execution pmd of goal org.apache.maven.plugins:maven-pmd-plugin:3.16.0:pmd
> failed: org.apache.maven.reporting.MavenReportException:
> org.eclipse.aether.resolution.DependencyResolutionException: The following
> artifacts could not be resolved: [REMOVED]: Failure to find [REMOVED] in
> https://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-invoker-plugin] dependabot[bot] commented on pull request #145: Bump slf4j-simple from 1.7.36 to 2.0.2
dependabot[bot] commented on PR #145: URL: https://github.com/apache/maven-invoker-plugin/pull/145#issuecomment-1256389686 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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
[GitHub] [maven-invoker-plugin] slawekjaranowski closed pull request #145: Bump slf4j-simple from 1.7.36 to 2.0.2
slawekjaranowski closed pull request #145: Bump slf4j-simple from 1.7.36 to 2.0.2 URL: https://github.com/apache/maven-invoker-plugin/pull/145 -- 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] (MINVOKER-310) Upgrade Parent to 37
[ https://issues.apache.org/jira/browse/MINVOKER-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MINVOKER-310. Resolution: Fixed > Upgrade Parent to 37 > > > Key: MINVOKER-310 > URL: https://issues.apache.org/jira/browse/MINVOKER-310 > Project: Maven Invoker Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-invoker-plugin] slawekjaranowski merged pull request #141: [MINVOKER-310] Upgrade Parent to 37
slawekjaranowski merged PR #141: URL: https://github.com/apache/maven-invoker-plugin/pull/141 -- 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
[GitHub] [maven] cstamas commented on a diff in pull request #806: Simpler G level metadata generation
cstamas commented on code in PR #806:
URL: https://github.com/apache/maven/pull/806#discussion_r978756688
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -124,7 +128,46 @@ public Collection finish( Collection art
}
}
}
-
return plugins.values();
}
+
+private PluginInfo extractPluginInfo( Artifact artifact )
+{
+// sanity: jar, no classifier and file exists
+if ( artifact != null
+&& "jar".equals( artifact.getExtension() )
+&& "".equals( artifact.getClassifier() )
+&& artifact.getFile() != null )
+{
+Path artifactPath = artifact.getFile().toPath();
+if ( Files.isRegularFile( artifactPath ) )
+{
+try ( JarFile artifactJar = new JarFile(
artifactPath.toFile(), false ) )
+{
+ZipEntry pluginDescriptorEntry = artifactJar.getEntry(
PLUGIN_DESCRIPTOR_LOCATION );
+
+if ( pluginDescriptorEntry != null )
+{
+InputStream is = artifactJar.getInputStream(
pluginDescriptorEntry );
+
+Reader reader = ReaderFactory.newXmlReader( is );
+
+PluginDescriptor pluginDescriptor =
+pluginDescriptorBuilder.build( reader,
artifactPath.toAbsolutePath().toString() );
+
+return new PluginInfo(
+pluginDescriptor.getGroupId(),
+pluginDescriptor.getArtifactId(),
+pluginDescriptor.getGoalPrefix(),
+pluginDescriptor.getName() );
+}
+}
+catch ( Exception e )
+{
+// ignore it for now
Review Comment:
This is too broad, but for example maven's ArtifactDeployerTest and
ArtifactInstallerTest (maven-compat) uses invalid JAR for tests :sob:
--
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
[GitHub] [maven] cstamas commented on a diff in pull request #806: Simpler G level metadata generation
cstamas commented on code in PR #806:
URL: https://github.com/apache/maven/pull/806#discussion_r978757139
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -124,7 +128,46 @@ public Collection finish( Collection art
}
}
}
-
return plugins.values();
}
+
+private PluginInfo extractPluginInfo( Artifact artifact )
+{
+// sanity: jar, no classifier and file exists
+if ( artifact != null
+&& "jar".equals( artifact.getExtension() )
+&& "".equals( artifact.getClassifier() )
+&& artifact.getFile() != null )
+{
+Path artifactPath = artifact.getFile().toPath();
+if ( Files.isRegularFile( artifactPath ) )
+{
+try ( JarFile artifactJar = new JarFile(
artifactPath.toFile(), false ) )
+{
+ZipEntry pluginDescriptorEntry = artifactJar.getEntry(
PLUGIN_DESCRIPTOR_LOCATION );
+
+if ( pluginDescriptorEntry != null )
+{
+InputStream is = artifactJar.getInputStream(
pluginDescriptorEntry );
+
+Reader reader = ReaderFactory.newXmlReader( is );
+
+PluginDescriptor pluginDescriptor =
+pluginDescriptorBuilder.build( reader,
artifactPath.toAbsolutePath().toString() );
Review Comment:
Maybe just load up DOM and drop plugin-api/plexus as deps?
--
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
[GitHub] [maven] cstamas commented on a diff in pull request #806: Simpler G level metadata generation
cstamas commented on code in PR #806: URL: https://github.com/apache/maven/pull/806#discussion_r978755339 ## maven-resolver-provider/pom.xml: ## @@ -103,6 +107,13 @@ under the License. failureaccess true + + + + org.eclipse.sisu + org.eclipse.sisu.plexus Review Comment: Needed for model and as builder throws PlexusConfEx :sob: Maybe just slurp in the plugin.xml as DOM? -- 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
[GitHub] [maven] cstamas commented on a diff in pull request #806: Simpler G level metadata generation
cstamas commented on code in PR #806: URL: https://github.com/apache/maven/pull/806#discussion_r978754793 ## maven-resolver-provider/pom.xml: ## @@ -34,6 +34,10 @@ under the License. Extensions to Maven Resolver for utilizing Maven POM and repository metadata. + + org.apache.maven + maven-plugin-api + Review Comment: Needed to grab PluginDescriptor model, that needs plexus... :cry: -- 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
[GitHub] [maven] cstamas opened a new pull request, #806: Simpler G level metadata generation
cstamas opened a new pull request, #806: URL: https://github.com/apache/maven/pull/806 Just inspect deployed artifacts, try to find a plugin among them and reuse PluginDescriptor embedded in it. -- 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] (MNG-7546) A NullPointerException on recursive propety definition
Ondrej created MNG-7546:
---
Summary: A NullPointerException on recursive propety definition
Key: MNG-7546
URL: https://issues.apache.org/jira/browse/MNG-7546
Project: Maven
Issue Type: Bug
Components: Bootstrap & Build
Affects Versions: 3.8.6
Reporter: Ondrej
A NPE occured when I have changed some versions to a ${...} expression using
find & replace.
That also replaced the property definition:
<{color:#002586}version.testcontainers{color}>${version.testcontainers}
...
<{color:#002586}dependency{color}><{color:#002586}groupId{color}>org.testcontainers<{color:#002586}artifactId{color}>testcontainers<{color:#002586}type{color}>pom<{color:#002586}version{color}>${version.testcontainers}<{color:#002586}scope{color}>test
This resulted in the following NPE:
{code:java}
/usr/lib/jvm/java-1.18.0-openjdk-amd64/bin/java
-Dmaven.multiModuleProjectDirectory=/home/o/work/tracker-service/tracker-service
-Dmaven.home=/snap/intellij-idea-community/387/plugins/maven/lib/maven3
-Dclassworlds.conf=/snap/intellij-idea-community/387/plugins/maven/lib/maven3/bin/m2.conf
-Dmaven.ext.class.path=/snap/intellij-idea-community/387/plugins/maven/lib/maven-event-listener.jar
-javaagent:/snap/intellij-idea-community/387/lib/idea_rt.jar=46145:/snap/intellij-idea-community/387/bin
-Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8
-classpath
/snap/intellij-idea-community/387/plugins/maven/lib/maven3/boot/plexus-classworlds-2.6.0.jar:/snap/intellij-idea-community/387/plugins/maven/lib/maven3/boot/plexus-classworlds.license
org.codehaus.classworlds.Launcher -Didea.version=2022.2.2 compile
[INFO] Scanning for projects...
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:104)
at java.lang.reflect.Method.invoke (Method.java:577)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
at org.codehaus.classworlds.Launcher.main (Launcher.java:47)
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap$MapEntry.setValue
(ConcurrentHashMap.java:3546)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
(StringVisitorModelInterpolator.java:1429)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
(StringVisitorModelInterpolator.java:1027)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
(StringVisitorModelInterpolator.java:170)
at
org.apache.maven.model.interpolation.StringVisitorModelInterpolator.interpolateModel
(StringVisitorModelInterpolator.java:107)
at org.apache.maven.model.building.DefaultModelBuilder.interpolateModel
(DefaultModelBuilder.java:789)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:393)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:448)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:414)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:377)
at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
(DefaultGraphBuilder.java:414)
at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
(DefaultGraphBuilder.java:405)
at org.apache.maven.graph.DefaultGraphBuilder.build
(DefaultGraphBuilder.java:82)
at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:104)
at java.lang.reflect.Method.invoke (Method.java:577)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.
[jira] [Comment Edited] (MJAVADOC-732) Use javax.tools API for calling javadoc
[
https://issues.apache.org/jira/browse/MJAVADOC-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608736#comment-17608736
]
Konrad Windszus edited comment on MJAVADOC-732 at 9/23/22 1:03 PM:
---
IIUC m-compiler-p also uses javax.tools (at least optionally,
https://github.com/codehaus-plexus/plexus-compiler/blob/master/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavaxToolsCompiler.java)
. The same thing should work for javadoc.
I don't know what you meant by "building for Java 7", IMHO executing the Java 7
Javadoc is just not necessary (the output of the tool is poor compared to newer
version) so I don't see a use case for still using JDK7 javadoc. Regarding
forking: same as for m-compiler-p, in that case it would use the old approach,
compare with
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#forceJavacCompilerUse
and
https://github.com/codehaus-plexus/plexus-compiler/blob/79d1a5fdd237a736ad58fd346a975d5d37046a15/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java#L155-L188
was (Author: kwin):
IIUC m-compiler-p also uses javax.tools (at least optionally,
https://github.com/codehaus-plexus/plexus-compiler/blob/master/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavaxToolsCompiler.java)
. The same thing should work for javadoc.
I don't know what you meant by "building for Java 7", IMHO executing the Java 7
Javadoc is just not necessary (the output of the tool is poor compared to newer
version) so I don't see a use case for still using JDK7 javadoc. Regarding
forking: same as for m-compiler-p, in that case it would use the old approach,
compare with
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#forceJavacCompilerUse.
> Use javax.tools API for calling javadoc
> ---
>
> Key: MJAVADOC-732
> URL: https://issues.apache.org/jira/browse/MJAVADOC-732
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently javadoc is called as external process which makes
> consuming/exposing warnings and errors a bit cumbersome and also prevents
> proper m2e integration.
> As https://openjdk.org/jeps/106 added javadoc support to {{javax.tools}} with
> Java 8 it should be safe to adopt that given that m-javadoc-p has been
> updated to require Java 8 in MJAVADOC-675
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-732) Use javax.tools API for calling javadoc
[
https://issues.apache.org/jira/browse/MJAVADOC-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608736#comment-17608736
]
Konrad Windszus commented on MJAVADOC-732:
--
IIUC m-compiler-p also uses javax.tools (at least optionally,
https://github.com/codehaus-plexus/plexus-compiler/blob/master/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavaxToolsCompiler.java)
. The same thing should work for javadoc.
I don't know what you meant by "building for Java 7", IMHO executing the Java 7
Javadoc is just not necessary (the output of the tool is poor compared to newer
version) so I don't see a use case for still using JDK7 javadoc. Regarding
forking: same as for m-compiler-p, in that case it would use the old approach,
compare with
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#forceJavacCompilerUse.
> Use javax.tools API for calling javadoc
> ---
>
> Key: MJAVADOC-732
> URL: https://issues.apache.org/jira/browse/MJAVADOC-732
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently javadoc is called as external process which makes
> consuming/exposing warnings and errors a bit cumbersome and also prevents
> proper m2e integration.
> As https://openjdk.org/jeps/106 added javadoc support to {{javax.tools}} with
> Java 8 it should be safe to adopt that given that m-javadoc-p has been
> updated to require Java 8 in MJAVADOC-675
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-732) Use javax.tools API for calling javadoc
[
https://issues.apache.org/jira/browse/MJAVADOC-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608709#comment-17608709
]
Michael Osipov commented on MJAVADOC-732:
-
What about toolchains? What about building for Java 7? What about forking?
> Use javax.tools API for calling javadoc
> ---
>
> Key: MJAVADOC-732
> URL: https://issues.apache.org/jira/browse/MJAVADOC-732
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently javadoc is called as external process which makes
> consuming/exposing warnings and errors a bit cumbersome and also prevents
> proper m2e integration.
> As https://openjdk.org/jeps/106 added javadoc support to {{javax.tools}} with
> Java 8 it should be safe to adopt that given that m-javadoc-p has been
> updated to require Java 8 in MJAVADOC-675
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] 1013461195 closed issue #674: mvnd not extends parent properties？
1013461195 closed issue #674: mvnd not extends parent properties？ URL: https://github.com/apache/maven-mvnd/issues/674 -- 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] (MNGSITE-488) Add Bootstrap Site Skin to documentation
[ https://issues.apache.org/jira/browse/MNGSITE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608641#comment-17608641 ] ASF GitHub Bot commented on MNGSITE-488: stevecrox commented on PR #314: URL: https://github.com/apache/maven-site/pull/314#issuecomment-1255958858 Is there anything outstanding for me to do? > Add Bootstrap Site Skin to documentation > > > Key: MNGSITE-488 > URL: https://issues.apache.org/jira/browse/MNGSITE-488 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Stephen Crocker >Priority: Minor > > I have developed a new Maven Site skin based on Bootstrap 5 components and > elements which can be toggled on/off allowing a variety of layouts. > The areas of the community I have shared this with have suggested placing it > into the available skin documentation so other projects can find it. > This feature is adding that information to the relevant documentation page. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-site] stevecrox commented on pull request #314: MSITE-909 - Added new Site skin information to documentation
stevecrox commented on PR #314: URL: https://github.com/apache/maven-site/pull/314#issuecomment-1255958858 Is there anything outstanding for me to do? -- 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] (MJAVADOC-732) Use javax.tools API for calling javadoc
Konrad Windszus created MJAVADOC-732:
Summary: Use javax.tools API for calling javadoc
Key: MJAVADOC-732
URL: https://issues.apache.org/jira/browse/MJAVADOC-732
Project: Maven Javadoc Plugin
Issue Type: Improvement
Components: javadoc
Reporter: Konrad Windszus
Currently javadoc is called as external process which makes consuming/exposing
warnings and errors a bit cumbersome and also prevents proper m2e integration.
As https://openjdk.org/jeps/106 added javadoc support to {{javax.tools}} with
Java 8 it should be safe to adopt that given that m-javadoc-p has been updated
to require Java 8 in MJAVADOC-675
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1105) when running with mvnDebug the spawned process in in debug mode as well
[ https://issues.apache.org/jira/browse/MRELEASE-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608616#comment-17608616 ] Michael Osipov commented on MRELEASE-1105: -- We should stop propagating `MAVEN_*` environment variables to subprocesses. They should be clean in regards to this. > when running with mvnDebug the spawned process in in debug mode as well > > > Key: MRELEASE-1105 > URL: https://issues.apache.org/jira/browse/MRELEASE-1105 > Project: Maven Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 3.0.0-M6 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.0.0-M7 > > > because env vars are propagated... > `MAVEN_DEBUG_OPTS` should be forced to "" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRELEASE-1105) when running with mvnDebug the spawned process in in debug mode as well
[
https://issues.apache.org/jira/browse/MRELEASE-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608616#comment-17608616
]
Michael Osipov edited comment on MRELEASE-1105 at 9/23/22 8:13 AM:
---
We should stop propagating {{MAVEN_*}} environment variables to subprocesses.
They should be clean in regards to this.
was (Author: michael-o):
We should stop propagating `MAVEN_*` environment variables to subprocesses.
They should be clean in regards to this.
> when running with mvnDebug the spawned process in in debug mode as well
>
>
> Key: MRELEASE-1105
> URL: https://issues.apache.org/jira/browse/MRELEASE-1105
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M6
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> because env vars are propagated...
> `MAVEN_DEBUG_OPTS` should be forced to ""
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1104) stage goal doesn’t use stagingRepository parameter
[ https://issues.apache.org/jira/browse/MRELEASE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608595#comment-17608595 ] Olivier Lamy commented on MRELEASE-1104: PR https://github.com/apache/maven-release/pull/151 > stage goal doesn’t use stagingRepository parameter > -- > > Key: MRELEASE-1104 > URL: https://issues.apache.org/jira/browse/MRELEASE-1104 > Project: Maven Release Plugin > Issue Type: Bug > Components: stage >Affects Versions: 3.0.0-M6 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.0.0-M7 > > > reported here: [https://github.com/jenkins-infra/helpdesk/issues/3143] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-release] olamy opened a new pull request, #151: [MRELEASE-1104] fix stage goal when having both arguments and stagingRepository
olamy opened a new pull request, #151: URL: https://github.com/apache/maven-release/pull/151 Signed-off-by: Olivier Lamy Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJAVADOC) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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] (MRELEASE-1105) when running with mvnDebug the spawned process in in debug mode as well
[ https://issues.apache.org/jira/browse/MRELEASE-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRELEASE-1105: --- Fix Version/s: 3.0.0-M7 > when running with mvnDebug the spawned process in in debug mode as well > > > Key: MRELEASE-1105 > URL: https://issues.apache.org/jira/browse/MRELEASE-1105 > Project: Maven Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 3.0.0-M6 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.0.0-M7 > > > because env vars are propagated... > `MAVEN_DEBUG_OPTS` should be forced to "" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRELEASE-1105) when running with mvnDebug the spawned process in in debug mode as well
Olivier Lamy created MRELEASE-1105: -- Summary: when running with mvnDebug the spawned process in in debug mode as well Key: MRELEASE-1105 URL: https://issues.apache.org/jira/browse/MRELEASE-1105 Project: Maven Release Plugin Issue Type: Bug Components: perform Affects Versions: 3.0.0-M6 Reporter: Olivier Lamy Assignee: Olivier Lamy because env vars are propagated... `MAVEN_DEBUG_OPTS` should be forced to "" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-275) Introduce trusted checksums source
[
https://issues.apache.org/jira/browse/MRESOLVER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-275:
--
Component/s: Resolver
> Introduce trusted checksums source
> --
>
> Key: MRESOLVER-275
> URL: https://issues.apache.org/jira/browse/MRESOLVER-275
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> Provided checksums are introduced as 3rd kind of ChecksumKind (external,
> inlined, provided). But new usses for provided checksums were requested in
> area that is not at all "transport" (connector, transport, artifact download)
> related at all, while {{ProvidedChecksumsSource}} interface is bound to
> "transport" (uses classes from transport).
> Hence, to make a clear distinction, introduce new component: "trusted"
> checksum source, that is generic, is not transport bound and "push" the
> existing implementation below, and adapt "trusted" checksum source into
> "provided" checksum source as needed. This clearly separates notion of
> "provided checksusm (for transport)" from "trusted checksums (usable across
> places not even transport related).
> Note: resolver does NOT do anything for "trust", it is completely up to
> implementation and user, how these checksums are obtained and does user
> trusts them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-273) Create more compact File locking layout/mapper
[ https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MRESOLVER-273: -- Component/s: Resolver > Create more compact File locking layout/mapper > -- > > Key: MRESOLVER-273 > URL: https://issues.apache.org/jira/browse/MRESOLVER-273 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long > paths, hence (relatively) big strings etc. > More compact layout would be just to hash strings like "a:G:A:V" and > "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep > hashed storage. > Problem with "loose" layout is that they do end up as files in OS, while > these would be much shorter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-276) Resolver post-processor
[ https://issues.apache.org/jira/browse/MRESOLVER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MRESOLVER-276: - Assignee: Tamás Cservenák > Resolver post-processor > --- > > Key: MRESOLVER-276 > URL: https://issues.apache.org/jira/browse/MRESOLVER-276 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Introduce new feature, resolver post-processor that is able to post process > resolution results just before artifact resolver returns them to caller. Post > processor should be able to signal resolution failure (along with errors) > just like existing resolution may fail. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-276) Resolver post-processor
Tamás Cservenák created MRESOLVER-276: - Summary: Resolver post-processor Key: MRESOLVER-276 URL: https://issues.apache.org/jira/browse/MRESOLVER-276 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamás Cservenák Introduce new feature, resolver post-processor that is able to post process resolution results just before artifact resolver returns them to caller. Post processor should be able to signal resolution failure (along with errors) just like existing resolution may fail. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-276) Resolver post-processor
[ https://issues.apache.org/jira/browse/MRESOLVER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MRESOLVER-276: -- Fix Version/s: resolver-next > Resolver post-processor > --- > > Key: MRESOLVER-276 > URL: https://issues.apache.org/jira/browse/MRESOLVER-276 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Introduce new feature, resolver post-processor that is able to post process > resolution results just before artifact resolver returns them to caller. Post > processor should be able to signal resolution failure (along with errors) > just like existing resolution may fail. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-269) Allow more compact storage of provided checksums
[ https://issues.apache.org/jira/browse/MRESOLVER-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MRESOLVER-269: -- Summary: Allow more compact storage of provided checksums (was: Allow storage of provided checksums in file format) > Allow more compact storage of provided checksums > > > Key: MRESOLVER-269 > URL: https://issues.apache.org/jira/browse/MRESOLVER-269 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Rafael Winterhalter >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > While the repository layout makes sense for storage outside of a project, it > would be more convenient to store checksums in a single file (per algorithm) > when keeping checksums along when storing these checksums within a project. > This makes the storage easier to version control and avoids the overhead of > storing a lot of files in version control what often creates some overhead. > Ideally, Maven could support such files out of the box by shipping a provider > for such files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-275) Introduce trusted checksums
[
https://issues.apache.org/jira/browse/MRESOLVER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-275:
--
Fix Version/s: resolver-next
> Introduce trusted checksums
> ---
>
> Key: MRESOLVER-275
> URL: https://issues.apache.org/jira/browse/MRESOLVER-275
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> Provided checksums are introduced as 3rd kind of ChecksumKind (external,
> inlined, provided). But new usses for provided checksums were requested in
> area that is not at all "transport" (connector, transport, artifact download)
> related at all, while {{ProvidedChecksumsSource}} interface is bound to
> "transport" (uses classes from transport).
> Hence, to make a clear distinction, introduce new component: "trusted"
> checksum source, that is generic, is not transport bound and "push" the
> existing implementation below, and adapt "trusted" checksum source into
> "provided" checksum source as needed. This clearly separates notion of
> "provided checksusm (for transport)" from "trusted checksums (usable across
> places not even transport related).
> Note: resolver does NOT do anything for "trust", it is completely up to
> implementation and user, how these checksums are obtained and does user
> trusts them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-275) Introduce trusted checksums source
[
https://issues.apache.org/jira/browse/MRESOLVER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MRESOLVER-275:
--
Summary: Introduce trusted checksums source (was: Introduce trusted
checksums)
> Introduce trusted checksums source
> --
>
> Key: MRESOLVER-275
> URL: https://issues.apache.org/jira/browse/MRESOLVER-275
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> Provided checksums are introduced as 3rd kind of ChecksumKind (external,
> inlined, provided). But new usses for provided checksums were requested in
> area that is not at all "transport" (connector, transport, artifact download)
> related at all, while {{ProvidedChecksumsSource}} interface is bound to
> "transport" (uses classes from transport).
> Hence, to make a clear distinction, introduce new component: "trusted"
> checksum source, that is generic, is not transport bound and "push" the
> existing implementation below, and adapt "trusted" checksum source into
> "provided" checksum source as needed. This clearly separates notion of
> "provided checksusm (for transport)" from "trusted checksums (usable across
> places not even transport related).
> Note: resolver does NOT do anything for "trust", it is completely up to
> implementation and user, how these checksums are obtained and does user
> trusts them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-275) Introduce trusted checksums
Tamás Cservenák created MRESOLVER-275:
-
Summary: Introduce trusted checksums
Key: MRESOLVER-275
URL: https://issues.apache.org/jira/browse/MRESOLVER-275
Project: Maven Resolver
Issue Type: Improvement
Reporter: Tamás Cservenák
Provided checksums are introduced as 3rd kind of ChecksumKind (external,
inlined, provided). But new usses for provided checksums were requested in area
that is not at all "transport" (connector, transport, artifact download)
related at all, while {{ProvidedChecksumsSource}} interface is bound to
"transport" (uses classes from transport).
Hence, to make a clear distinction, introduce new component: "trusted" checksum
source, that is generic, is not transport bound and "push" the existing
implementation below, and adapt "trusted" checksum source into "provided"
checksum source as needed. This clearly separates notion of "provided checksusm
(for transport)" from "trusted checksums (usable across places not even
transport related).
Note: resolver does NOT do anything for "trust", it is completely up to
implementation and user, how these checksums are obtained and does user trusts
them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-275) Introduce trusted checksums
[
https://issues.apache.org/jira/browse/MRESOLVER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák reassigned MRESOLVER-275:
-
Assignee: Tamás Cservenák
> Introduce trusted checksums
> ---
>
> Key: MRESOLVER-275
> URL: https://issues.apache.org/jira/browse/MRESOLVER-275
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
>
> Provided checksums are introduced as 3rd kind of ChecksumKind (external,
> inlined, provided). But new usses for provided checksums were requested in
> area that is not at all "transport" (connector, transport, artifact download)
> related at all, while {{ProvidedChecksumsSource}} interface is bound to
> "transport" (uses classes from transport).
> Hence, to make a clear distinction, introduce new component: "trusted"
> checksum source, that is generic, is not transport bound and "push" the
> existing implementation below, and adapt "trusted" checksum source into
> "provided" checksum source as needed. This clearly separates notion of
> "provided checksusm (for transport)" from "trusted checksums (usable across
> places not even transport related).
> Note: resolver does NOT do anything for "trust", it is completely up to
> implementation and user, how these checksums are obtained and does user
> trusts them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
