[GitHub] [maven-build-cache-extension] dependabot[bot] opened a new pull request, #97: Bump org.testcontainers:testcontainers-bom from 1.18.3 to 1.19.0
dependabot[bot] opened a new pull request, #97: URL: https://github.com/apache/maven-build-cache-extension/pull/97 Bumps [org.testcontainers:testcontainers-bom](https://github.com/testcontainers/testcontainers-java) from 1.18.3 to 1.19.0. Release notes Sourced from https://github.com/testcontainers/testcontainers-java/releases";>org.testcontainers:testcontainers-bom's releases. 1.19.0 Testcontainers for Java 1.19.0 Core Add support for compose v2 with ComposeContainer (https://redirect.github.com/testcontainers/testcontainers-java/issues/5608";>#5608) https://github.com/eddumelendez";>@eddumelendez Allow command execution with custom user (https://redirect.github.com/testcontainers/testcontainers-java/issues/7311";>#7311) https://github.com/megglos";>@megglos Add Wait.forListeningPorts(ports) (https://redirect.github.com/testcontainers/testcontainers-java/issues/7402";>#7402) https://github.com/eddumelendez";>@eddumelendez Enable Ryuk as a privileged container by default (https://redirect.github.com/testcontainers/testcontainers-java/issues/7319";>#7319) https://github.com/eddumelendez";>@eddumelendez Use SelinuxContext.SHARED by default (https://redirect.github.com/testcontainers/testcontainers-java/issues/7187";>#7187) https://github.com/jeroen-vd-nl";>@jeroen-vd-nl Add interface to customize CreateContainerCmd (https://redirect.github.com/testcontainers/testcontainers-java/issues/7421";>#7421) https://github.com/eddumelendez";>@eddumelendez Modules ClickHouse Add new ClickHouseContainer implementation (https://redirect.github.com/testcontainers/testcontainers-java/issues/7403";>#7403) https://github.com/eddumelendez";>@eddumelendez Elasticsearch Disable default geoip database downloading (https://redirect.github.com/testcontainers/testcontainers-java/issues/7247";>#7247) https://github.com/lhotari";>@lhotari Disable default disk threshold check (https://redirect.github.com/testcontainers/testcontainers-java/issues/7245";>#7245) https://github.com/lhotari";>@lhotari DB2 Support http://icr.io/db2_community/db2";>icr.io/db2_community/db2 as a compatible image (https://redirect.github.com/testcontainers/testcontainers-java/issues/7397";>#7397) https://github.com/eddumelendez";>@eddumelendez GCloud Add BigQueryEmulatorContainer (https://redirect.github.com/testcontainers/testcontainers-java/issues/7324";>#7324) https://github.com/eddumelendez";>@eddumelendez Expose getProjectId in DatastoreEmulatorContainer (https://redirect.github.com/testcontainers/testcontainers-java/issues/7328";>#7328) https://github.com/eddumelendez";>@eddumelendez Support String image in Bigtable, Firestore, PubSub, Spanner (https://redirect.github.com/testcontainers/testcontainers-java/issues/7327";>#7327) https://github.com/eddumelendez";>@eddumelendez JUnit Jupiter Fix call to stop containers when using @Testcontainers(parallel = true) (https://redirect.github.com/testcontainers/testcontainers-java/issues/7394";>#7394) https://github.com/eddumelendez";>@eddumelendez Kafka Allow to register additional listeners (https://redirect.github.com/testcontainers/testcontainers-java/issues/7333";>#7333) https://github.com/eddumelendez";>@eddumelendez See https://java.testcontainers.org/modules/kafka/";>https://java.testcontainers.org/modules/kafka/ MS SQL Server Fix MSSQL's default username (https://redirect.github.com/testcontainers/testcontainers-java/issues/7238";>#7238) https://github.com/Eng-Fouad";>@Eng-Fouad QuestDB Add questdb as a database provider (https://redirect.github.com/testcontainers/testcontainers-java/issues/7244";>#7244) https://github.com/eddumelendez";>@eddumelendez ... (truncated) Commits https://github.com/testcontainers/testcontainers-java/commit/15dcb62b68efa9a2db4fd98e841b3739bc7dea09";>15dcb62 Fix test https://github.com/testcontainers/testcontainers-java/commit/d9519f998bc81d6e3f11b459aab9bfe8776f42f7";>d9519f9 Add interface to customize CreateContainerCmd (https://redirect.github.com/testcontainers/testcontainers-java/issues/7421";>#7421) https://github.com/testcontainers/testcontainers-java/commit/6e817323b0dc664f0f6ae04b1a281d0d388811d1";>6e81732 Replace R2DBC Host by docker host ip address (https://redirect.github.com/testcontainers/testcontainers-java/issues/7431";>#7431) https://github.com/testcontainers/testcontainers-java/commit/06b915585ade7e17242cc04b7e4eb5730ddb1754";>06b9155 Add "new badge" in header (https://redirect.github.com/testcontainers/testcontainers-java/issues/7426";>#7426) https://github.com/testcontainers/testcontainers-java/commit/7b69ca0fdc71c12a9ec6f23eff7ab6fedc19388d";>7b69ca0 Update docker-java version to 3.3.3 (https://redirect.github.com/testcontainers/testcontainers-java/issues/7423";>#7423) https://github.com/testc
[GitHub] [maven-build-cache-extension] maximilian-novikov-db commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
maximilian-novikov-db commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301242760
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
i suggest to remove the filter here
https://github.com/apache/maven-build-cache-extension/blob/4d53a0a05c1e006265e19bce8ba8c9a0eb7831df/src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java#L137
and not to add Clean if it's not requested by user
--
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] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757245#comment-17757245
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
maximilian-novikov-db commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301242760
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
i suggest to remove the filter here
https://github.com/apache/maven-build-cache-extension/blob/4d53a0a05c1e006265e19bce8ba8c9a0eb7831df/src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java#L137
and not to add Clean if it's not requested by user
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> [I
[jira] [Commented] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757247#comment-17757247
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
maximilian-novikov-db commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301244654
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
@kbuntrock could you please move this change to a separate pr
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
> -
[GitHub] [maven-build-cache-extension] maximilian-novikov-db commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
maximilian-novikov-db commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301244654
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
@kbuntrock could you please move this change to a separate pr
--
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] norrisjeremy commented on pull request #1205: [MNG-5862] Support XML entities and XInclude
norrisjeremy commented on PR #1205: URL: https://github.com/apache/maven/pull/1205#issuecomment-1688015752 Is this wise? XML parsers are littered with a long history of security vulnerabilities around loading crap remotely. Introducing that into a build system seems scary to me. -- 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-5862) POM XML parser needs XInclude and/or XML Entity support
[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757389#comment-17757389
]
ASF GitHub Bot commented on MNG-5862:
-
norrisjeremy commented on PR #1205:
URL: https://github.com/apache/maven/pull/1205#issuecomment-1688015752
Is this wise?
XML parsers are littered with a long history of security vulnerabilities
around loading crap remotely.
Introducing that into a build system seems scary to me.
> POM XML parser needs XInclude and/or XML Entity support
> ---
>
> Key: MNG-5862
> URL: https://issues.apache.org/jira/browse/MNG-5862
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Jason Vas Dias
>Assignee: Guillaume Nodet
>Priority: Major
>
> POM XML files can get very large and repetitive , and not all modularizaton
> scenarios can be resolved by using a Super POM as described in MNG-1980 ,
> and would be easily resolved if only the POM parser supported XIncludes or
> XML Entities - neither are supported.
> Here is one such scenario:
> I have a large project that has several SureFire plugin based "Test Suites" -
> each test suite uses a "common-at-classes" module of common test classes,
> and is essentially identical except in its XML configuration "test resource"
> files
> - so the structure is like this :
> {quote}
> {noformat}
> Top Level project directory:
>./pom.xml
>./acceptance-tests/pom.xml
>./acceptance-tests/common-at-classes/pom.xml
>./acceptance-tests/test-suite_#1/pom.xml
>...
>./acceptance-tests/test-suite_#N/pom.xml
> {noformat}
> {quote}
> There are @ 10 ( being upgraded to @ 20) "test suites",
> which all do exactly the same thing, but with slightly
> different "test resource" configuration files,
> and depend on the 'acceptance-tests/common-at-classes" JAR .
> We can modularize all the test-suite dependencies OK in the single
> common-at-classes/pom.xml location .
> But their is no way to modularize the actual XML code that runs each
> test-suite with plugin executions - these plugin execution stanzas can
> currently ONLY
> be in each test-suite#N directory, even though they are identical.
> It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
> contain the plugin executions to run any single test suite ; nor can the
> common-at-classes/pom.xml contain the plugin execution to run any
> test suite, since a test suite run depends on the customized test resource
> files that only exist in each "test_suite#N/" sub-project .
> So the only solution currently available with Maven is to copy the XML stanzas
> that configure and run the test suite ( about 400 lines of XML ) into each of
> the 10-20 test-suite/pom.xml files ; this is all because Maven does not
> support
> XML XInclude or XML Entities; if it did, we could put all this code into one
> XML
> file provided by the common-at-classes project, and include it in each test
> suite .
> The test suite XML is then a nightmare to maintain, consistently for all test
> suites.
> This is becoming such a problem that I am considering making the root project
> POM do nothing more than transform the test-suite poms with XML XInclude-s
> (using an external XML processor), creating a new copy of the whole project,
> and then run an exec plugin goal which runs maven with the transformed POMs.
> Please, please can we have some form of XInclude or XML Entity support , or
> support for an "" element, in the POM parser !
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7822) Add TRACE("bold,magenta" ) to Style in org.apache.maven.shared.utils.logging for style.color.
[
https://issues.apache.org/jira/browse/MNG-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757394#comment-17757394
]
ASF GitHub Bot commented on MNG-7822:
-
elharo commented on code in PR #1215:
URL: https://github.com/apache/maven/pull/1215#discussion_r1301529188
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/MessageBuilder.java:
##
@@ -27,6 +27,16 @@
* @see MessageBuilderFactory
*/
public interface MessageBuilder {
+
+/**
+ * Append message content in trace style.
+ * By default, bold magenta
+ * @param message the message to append
Review Comment:
nit: blank line before first param
> Add TRACE("bold,magenta" ) to Style in org.apache.maven.shared.utils.logging
> for style.color.
> -
>
> Key: MNG-7822
> URL: https://issues.apache.org/jira/browse/MNG-7822
> Project: Maven
> Issue Type: New Feature
> Components: Logging
>Reporter: Richard O'Sullivan
>Priority: Trivial
>
> Maven uses 'Style' in 'org.apache.maven.shared.utils.logging' to enumerate
> the available logging levels. Currently, the 'TRACE' level is not enumerated.
> It would be helpful to add something like: 'TRACE("bold,magenta" ) '.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] elharo commented on a diff in pull request #1217: [MNG-7862] The ModelLocator should always be used when locating pom.xml
elharo commented on code in PR #1217:
URL: https://github.com/apache/maven/pull/1217#discussion_r1301532825
##
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelSource3.java:
##
@@ -0,0 +1,47 @@
+/*
+ * 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.model.building;
+
+import org.apache.maven.model.locator.ModelLocator;
+
+/**
+ * Enhancement to the {@link ModelSource2} to support locating POM files using
the {@link ModelLocator}
+ * when pointing to a directory.
+ */
+public interface ModelSource3 extends ModelSource2 {
+/**
+ * Returns model source identified by a path relative to this model source
POM. Implementation MUST
+ * be able to accept relPath parameter values that
Review Comment:
delete "be able to"
##
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelSource3.java:
##
@@ -0,0 +1,47 @@
+/*
+ * 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.model.building;
+
+import org.apache.maven.model.locator.ModelLocator;
+
+/**
+ * Enhancement to the {@link ModelSource2} to support locating POM files using
the {@link ModelLocator}
+ * when pointing to a directory.
+ */
+public interface ModelSource3 extends ModelSource2 {
+/**
+ * Returns model source identified by a path relative to this model source
POM. Implementation MUST
+ * be able to accept relPath parameter values that
+ *
+ * use either / or \ file path separator
+ * have .. parent directory references
+ * point either at file or directory, in the latter case the provided
{@code ModelLocator} will be used
Review Comment:
run-on sentence. Break up
##
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelSource3.java:
##
@@ -0,0 +1,47 @@
+/*
+ * 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.model.building;
+
+import org.apache.maven.model.locator.ModelLocator;
+
+/**
+ * Enhancement to the {@link ModelSource2} to support locating POM files using
the {@link ModelLocator}
+ * when pointing to a directory.
+ */
+public interface ModelSource3 extends ModelSource2 {
+/**
+ * Returns model source identified by a path relative to this model source
POM. Implementation MUST
+ * be able to accept relPath parameter values that
+ *
+ * use either / or \ file path separator
+ * have .. parent directory references
+ * point either at file or directory, in the latter case the provided
{@code ModelLocator} will be used
+ * to find the POM file, else if no locator is provided, a file named
'pom.xml' needs to be used by
[jira] [Commented] (MNG-7862) The ModelLocator should always be used when locating pom.xml
[
https://issues.apache.org/jira/browse/MNG-7862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757397#comment-17757397
]
ASF GitHub Bot commented on MNG-7862:
-
elharo commented on code in PR #1217:
URL: https://github.com/apache/maven/pull/1217#discussion_r1301532825
##
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelSource3.java:
##
@@ -0,0 +1,47 @@
+/*
+ * 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.model.building;
+
+import org.apache.maven.model.locator.ModelLocator;
+
+/**
+ * Enhancement to the {@link ModelSource2} to support locating POM files using
the {@link ModelLocator}
+ * when pointing to a directory.
+ */
+public interface ModelSource3 extends ModelSource2 {
+/**
+ * Returns model source identified by a path relative to this model source
POM. Implementation MUST
+ * be able to accept relPath parameter values that
Review Comment:
delete "be able to"
##
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelSource3.java:
##
@@ -0,0 +1,47 @@
+/*
+ * 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.model.building;
+
+import org.apache.maven.model.locator.ModelLocator;
+
+/**
+ * Enhancement to the {@link ModelSource2} to support locating POM files using
the {@link ModelLocator}
+ * when pointing to a directory.
+ */
+public interface ModelSource3 extends ModelSource2 {
+/**
+ * Returns model source identified by a path relative to this model source
POM. Implementation MUST
+ * be able to accept relPath parameter values that
+ *
+ * use either / or \ file path separator
+ * have .. parent directory references
+ * point either at file or directory, in the latter case the provided
{@code ModelLocator} will be used
Review Comment:
run-on sentence. Break up
##
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelSource3.java:
##
@@ -0,0 +1,47 @@
+/*
+ * 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.model.building;
+
+import org.apache.maven.model.locator.ModelLocator;
+
+/**
+ * Enhancement to the {@link ModelSource2} to support locating POM files using
the {@link ModelLocator}
+ * when pointing to a directory.
+ */
+public interface ModelSource3 extends ModelSource2 {
+/**
+ * Returns model source identified by a path relative to this model source
POM. Implementation MUST
+ * be able to accept relPath parameter values that
+ *
+ * use either / or \ file path separator
+ * ha
[GitHub] [maven-artifact-transfer] dependabot[bot] opened a new pull request, #95: Bump org.codehaus.groovy:groovy from 3.0.17 to 3.0.19
dependabot[bot] opened a new pull request, #95: URL: https://github.com/apache/maven-artifact-transfer/pull/95 Bumps [org.codehaus.groovy:groovy](https://github.com/apache/groovy) from 3.0.17 to 3.0.19. Commits See full diff in https://github.com/apache/groovy/commits";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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-artifact-transfer] dependabot[bot] commented on pull request #94: Bump groovy from 3.0.17 to 3.0.18
dependabot[bot] commented on PR #94: URL: https://github.com/apache/maven-artifact-transfer/pull/94#issuecomment-1688055248 Superseded by #95. -- 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-artifact-transfer] dependabot[bot] closed pull request #94: Bump groovy from 3.0.17 to 3.0.18
dependabot[bot] closed pull request #94: Bump groovy from 3.0.17 to 3.0.18 URL: https://github.com/apache/maven-artifact-transfer/pull/94 -- 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] (MENFORCER-490) Properly declare dependencies
Elliotte Rusty Harold created MENFORCER-490: --- Summary: Properly declare dependencies Key: MENFORCER-490 URL: https://issues.apache.org/jira/browse/MENFORCER-490 Project: Maven Enforcer Plugin Issue Type: Bug Reporter: Elliotte Rusty Harold mvn dependency:analyze reveals a number of undeclared dependencies in various sub modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MENFORCER-490) Properly declare dependencies
[ https://issues.apache.org/jira/browse/MENFORCER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MENFORCER-490: --- Assignee: Elliotte Rusty Harold > Properly declare dependencies > - > > Key: MENFORCER-490 > URL: https://issues.apache.org/jira/browse/MENFORCER-490 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > mvn dependency:analyze reveals a number of undeclared dependencies in various > sub modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-490) Properly declare dependencies
[ https://issues.apache.org/jira/browse/MENFORCER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757408#comment-17757408 ] ASF GitHub Bot commented on MENFORCER-490: -- elharo opened a new pull request, #282: URL: https://github.com/apache/maven-enforcer/pull/282 MENFORCER-490 is going to take multiple PRs to work through. This starts with a couple of the simpler fixes. > Properly declare dependencies > - > > Key: MENFORCER-490 > URL: https://issues.apache.org/jira/browse/MENFORCER-490 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > mvn dependency:analyze reveals a number of undeclared dependencies in various > sub modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] gnodet commented on issue #877: Failed to load native library:jansi-2.4.0-d705f3ccea969984-libjansi.so
gnodet commented on issue #877: URL: https://github.com/apache/maven-mvnd/issues/877#issuecomment-1688107602 @nick-ling please check the message `The native library file at /tmp/jansi-2.4.0-51613297cfd7b049-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64` -- 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-mvnd] gnodet commented on issue #793: java.lang.UnsatisfiedLinkError: Can't load library: jansi.dll
gnodet commented on issue #793: URL: https://github.com/apache/maven-mvnd/issues/793#issuecomment-1688131501 This looks like a jansi problem, see https://github.com/fusesource/jansi/issues/245 and https://issues.apache.org/jira/browse/MNG-7245. A workaround is to specify an alternative directory using `jansi.tmpdir` -- 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] norrisjeremy commented on a diff in pull request #1205: [MNG-5862] Support XML entities and XInclude
norrisjeremy commented on code in PR #1205:
URL: https://github.com/apache/maven/pull/1205#discussion_r1301595222
##
maven-model-builder/src/main/java/org/apache/maven/model/io/DefaultModelReader.java:
##
@@ -104,16 +113,53 @@ private TransformerContext
getTransformerContext(Map options) {
private Model read(InputStream input, Path pomFile, Map
options) throws IOException {
try {
+InputSource source = getSource(options);
+boolean strict = isStrict(options);
XMLInputFactory factory = new com.ctc.wstx.stax.WstxInputFactory();
-
factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, false);
-XMLStreamReader parser = factory.createXMLStreamReader(input);
+XMLOutputFactory outputFactory = new
com.ctc.wstx.stax.WstxOutputFactory();
+
+XMLStreamReader parser;
+// We only support xml entities and xinclude when reading a file
in strict mode
+if (pomFile != null && strict) {
+XMLResolver resolver = (String publicID, String systemID,
String baseURI, String namespace) -> {
+if (systemID == null) {
+throw new XMLStreamException("systemID is null");
+}
+if (baseURI == null) {
+throw new XMLStreamException("baseURI is null");
+}
+URI sysUri;
+try {
+sysUri = new URI(systemID);
+} catch (URISyntaxException e) {
+throw new XMLStreamException("Invalid syntax for
systemID uri: " + systemID, e);
+}
+if (sysUri.isAbsolute()) {
+throw new XMLStreamException("systemID must be a
relative URL: " + systemID);
+}
+try {
+URL url = URI.create(baseURI).resolve(sysUri).toURL();
+return new StreamSource(url.openStream(),
url.toExternalForm());
+} catch (IOException e) {
+throw new XMLStreamException("Unable to create Source
for " + systemID, e);
+}
+};
+
factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, true);
+
factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, true);
+factory.setProperty(WstxInputProperties.P_ENTITY_RESOLVER,
resolver);
+parser = new XIncludeStreamReader(
+factory,
+outputFactory,
+pomFile.toUri().toString(),
+factory.createXMLStreamReader(new
StaxPathInputSource(pomFile, input)));
+} else {
+parser = factory.createXMLStreamReader(new
StreamSource(input));
Review Comment:
Should there be a
`factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, false);`
call here?
##
maven-model-builder/src/main/java/org/apache/maven/model/io/DefaultModelReader.java:
##
@@ -104,16 +113,53 @@ private TransformerContext
getTransformerContext(Map options) {
private Model read(InputStream input, Path pomFile, Map
options) throws IOException {
try {
+InputSource source = getSource(options);
+boolean strict = isStrict(options);
XMLInputFactory factory = new com.ctc.wstx.stax.WstxInputFactory();
-
factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, false);
-XMLStreamReader parser = factory.createXMLStreamReader(input);
+XMLOutputFactory outputFactory = new
com.ctc.wstx.stax.WstxOutputFactory();
+
+XMLStreamReader parser;
+// We only support xml entities and xinclude when reading a file
in strict mode
+if (pomFile != null && strict) {
+XMLResolver resolver = (String publicID, String systemID,
String baseURI, String namespace) -> {
+if (systemID == null) {
+throw new XMLStreamException("systemID is null");
+}
+if (baseURI == null) {
+throw new XMLStreamException("baseURI is null");
+}
+URI sysUri;
+try {
+sysUri = new URI(systemID);
+} catch (URISyntaxException e) {
+throw new XMLStreamException("Invalid syntax for
systemID uri: " + systemID, e);
+}
+if (sysUri.isAbsolute()) {
+throw new XMLStreamException("systemID must be a
relative URL: " + systemID);
+}
+try {
+URL url = URI.create(baseURI).resolve(sysUri).toURL();
+
[jira] [Commented] (MNG-5862) POM XML parser needs XInclude and/or XML Entity support
[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757435#comment-17757435
]
ASF GitHub Bot commented on MNG-5862:
-
norrisjeremy commented on code in PR #1205:
URL: https://github.com/apache/maven/pull/1205#discussion_r1301595222
##
maven-model-builder/src/main/java/org/apache/maven/model/io/DefaultModelReader.java:
##
@@ -104,16 +113,53 @@ private TransformerContext
getTransformerContext(Map options) {
private Model read(InputStream input, Path pomFile, Map
options) throws IOException {
try {
+InputSource source = getSource(options);
+boolean strict = isStrict(options);
XMLInputFactory factory = new com.ctc.wstx.stax.WstxInputFactory();
-
factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, false);
-XMLStreamReader parser = factory.createXMLStreamReader(input);
+XMLOutputFactory outputFactory = new
com.ctc.wstx.stax.WstxOutputFactory();
+
+XMLStreamReader parser;
+// We only support xml entities and xinclude when reading a file
in strict mode
+if (pomFile != null && strict) {
+XMLResolver resolver = (String publicID, String systemID,
String baseURI, String namespace) -> {
+if (systemID == null) {
+throw new XMLStreamException("systemID is null");
+}
+if (baseURI == null) {
+throw new XMLStreamException("baseURI is null");
+}
+URI sysUri;
+try {
+sysUri = new URI(systemID);
+} catch (URISyntaxException e) {
+throw new XMLStreamException("Invalid syntax for
systemID uri: " + systemID, e);
+}
+if (sysUri.isAbsolute()) {
+throw new XMLStreamException("systemID must be a
relative URL: " + systemID);
+}
+try {
+URL url = URI.create(baseURI).resolve(sysUri).toURL();
+return new StreamSource(url.openStream(),
url.toExternalForm());
+} catch (IOException e) {
+throw new XMLStreamException("Unable to create Source
for " + systemID, e);
+}
+};
+
factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, true);
+
factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, true);
+factory.setProperty(WstxInputProperties.P_ENTITY_RESOLVER,
resolver);
+parser = new XIncludeStreamReader(
+factory,
+outputFactory,
+pomFile.toUri().toString(),
+factory.createXMLStreamReader(new
StaxPathInputSource(pomFile, input)));
+} else {
+parser = factory.createXMLStreamReader(new
StreamSource(input));
Review Comment:
Should there be a
`factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, false);`
call here?
##
maven-model-builder/src/main/java/org/apache/maven/model/io/DefaultModelReader.java:
##
@@ -104,16 +113,53 @@ private TransformerContext
getTransformerContext(Map options) {
private Model read(InputStream input, Path pomFile, Map
options) throws IOException {
try {
+InputSource source = getSource(options);
+boolean strict = isStrict(options);
XMLInputFactory factory = new com.ctc.wstx.stax.WstxInputFactory();
-
factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES, false);
-XMLStreamReader parser = factory.createXMLStreamReader(input);
+XMLOutputFactory outputFactory = new
com.ctc.wstx.stax.WstxOutputFactory();
+
+XMLStreamReader parser;
+// We only support xml entities and xinclude when reading a file
in strict mode
+if (pomFile != null && strict) {
+XMLResolver resolver = (String publicID, String systemID,
String baseURI, String namespace) -> {
+if (systemID == null) {
+throw new XMLStreamException("systemID is null");
+}
+if (baseURI == null) {
+throw new XMLStreamException("baseURI is null");
+}
+URI sysUri;
+try {
+sysUri = new URI(systemID);
+} catch (URISyntaxException e) {
+throw new XMLStreamException("Invalid syntax for
systemID uri: " + systemID, e);
+}
+if (sysUri.isAbsolut
[GitHub] [maven] gnodet commented on pull request #1205: [MNG-5862] Support XML entities and XInclude
gnodet commented on PR #1205: URL: https://github.com/apache/maven/pull/1205#issuecomment-1688143857 > Is this wise? > XML parsers are littered with a long history of security vulnerabilities around loading crap remotely. > Introducing that into a build system seems scary to me. I tried to mitigate the risks by only loading from rejecting any absolute URI. Also, no file with such entities / xinclude import should end up in maven central, those are translated when installed / uploaded. So this should only happen at build time, for the pom.xml that are parts of the build. The security problems are then kinda in the hand of the developper I would think. -- 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-5862) POM XML parser needs XInclude and/or XML Entity support
[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757443#comment-17757443
]
ASF GitHub Bot commented on MNG-5862:
-
gnodet commented on PR #1205:
URL: https://github.com/apache/maven/pull/1205#issuecomment-1688143857
> Is this wise?
> XML parsers are littered with a long history of security vulnerabilities
around loading crap remotely.
> Introducing that into a build system seems scary to me.
I tried to mitigate the risks by only loading from rejecting any absolute
URI. Also, no file with such entities / xinclude import should end up in maven
central, those are translated when installed / uploaded. So this should only
happen at build time, for the pom.xml that are parts of the build. The
security problems are then kinda in the hand of the developper I would think.
> POM XML parser needs XInclude and/or XML Entity support
> ---
>
> Key: MNG-5862
> URL: https://issues.apache.org/jira/browse/MNG-5862
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Jason Vas Dias
>Assignee: Guillaume Nodet
>Priority: Major
>
> POM XML files can get very large and repetitive , and not all modularizaton
> scenarios can be resolved by using a Super POM as described in MNG-1980 ,
> and would be easily resolved if only the POM parser supported XIncludes or
> XML Entities - neither are supported.
> Here is one such scenario:
> I have a large project that has several SureFire plugin based "Test Suites" -
> each test suite uses a "common-at-classes" module of common test classes,
> and is essentially identical except in its XML configuration "test resource"
> files
> - so the structure is like this :
> {quote}
> {noformat}
> Top Level project directory:
>./pom.xml
>./acceptance-tests/pom.xml
>./acceptance-tests/common-at-classes/pom.xml
>./acceptance-tests/test-suite_#1/pom.xml
>...
>./acceptance-tests/test-suite_#N/pom.xml
> {noformat}
> {quote}
> There are @ 10 ( being upgraded to @ 20) "test suites",
> which all do exactly the same thing, but with slightly
> different "test resource" configuration files,
> and depend on the 'acceptance-tests/common-at-classes" JAR .
> We can modularize all the test-suite dependencies OK in the single
> common-at-classes/pom.xml location .
> But their is no way to modularize the actual XML code that runs each
> test-suite with plugin executions - these plugin execution stanzas can
> currently ONLY
> be in each test-suite#N directory, even though they are identical.
> It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
> contain the plugin executions to run any single test suite ; nor can the
> common-at-classes/pom.xml contain the plugin execution to run any
> test suite, since a test suite run depends on the customized test resource
> files that only exist in each "test_suite#N/" sub-project .
> So the only solution currently available with Maven is to copy the XML stanzas
> that configure and run the test suite ( about 400 lines of XML ) into each of
> the 10-20 test-suite/pom.xml files ; this is all because Maven does not
> support
> XML XInclude or XML Entities; if it did, we could put all this code into one
> XML
> file provided by the common-at-classes project, and include it in each test
> suite .
> The test suite XML is then a nightmare to maintain, consistently for all test
> suites.
> This is becoming such a problem that I am considering making the root project
> POM do nothing more than transform the test-suite poms with XML XInclude-s
> (using an external XML processor), creating a new copy of the whole project,
> and then run an exec plugin goal which runs maven with the transformed POMs.
> Please, please can we have some form of XInclude or XML Entity support , or
> support for an "" element, in the POM parser !
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1217: [MNG-7862] The ModelLocator should always be used when locating pom.xml
gnodet commented on PR #1217: URL: https://github.com/apache/maven/pull/1217#issuecomment-1688153034 > Is this for v4 only? Some of the API changes look incompatible. Yes, I did not really envision to backport it. I think most of the changed methods are new in 4.0. The exceptions are the default value in the model and the new `ModelSource3` which I introduced to avoid adding a method to an interface that could be possibly implemented by plugins / extensions. I may have missed a possible incompatible change if a plugin/extension actually implements `ModelSource2` (as I should provide the previous behaviour in such a case). -- 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] norrisjeremy commented on pull request #1205: [MNG-5862] Support XML entities and XInclude
norrisjeremy commented on PR #1205: URL: https://github.com/apache/maven/pull/1205#issuecomment-1688154238 > I tried to mitigate the risks by only loading from rejecting any absolute URI. Also, no file with such entities / xinclude import should end up in maven central, those are translated when installed / uploaded. So this should only happen at build time, for the pom.xml that are parts of the build. The security problems are then kinda in the hand of the developper I would think. > > That's said, I'd like to find a consensus, and if it's seen as too risky, we could go with only mixins. That's the whole point of the discussion I started on dev. Would you consider adding a CLI option that a user can specify to Maven to explicitly tell it not to support remote entities / xinclude stuff (and possibly even default the option to having remote entities / xinclude off)? That could help allay concerns, in that users would have to explicitly opt-in (or have an ability to explicitly opt-out) to enabling this new potentially risky behavior. -- 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-5862) POM XML parser needs XInclude and/or XML Entity support
[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757457#comment-17757457
]
ASF GitHub Bot commented on MNG-5862:
-
norrisjeremy commented on PR #1205:
URL: https://github.com/apache/maven/pull/1205#issuecomment-1688154238
> I tried to mitigate the risks by only loading from rejecting any absolute
URI. Also, no file with such entities / xinclude import should end up in maven
central, those are translated when installed / uploaded. So this should only
happen at build time, for the pom.xml that are parts of the build. The security
problems are then kinda in the hand of the developper I would think.
>
> That's said, I'd like to find a consensus, and if it's seen as too risky,
we could go with only mixins. That's the whole point of the discussion I
started on dev.
Would you consider adding a CLI option that a user can specify to Maven to
explicitly tell it not to support remote entities / xinclude stuff (and
possibly even default the option to having remote entities / xinclude off)?
That could help allay concerns, in that users would have to explicitly
opt-in (or have an ability to explicitly opt-out) to enabling this new
potentially risky behavior.
> POM XML parser needs XInclude and/or XML Entity support
> ---
>
> Key: MNG-5862
> URL: https://issues.apache.org/jira/browse/MNG-5862
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Jason Vas Dias
>Assignee: Guillaume Nodet
>Priority: Major
>
> POM XML files can get very large and repetitive , and not all modularizaton
> scenarios can be resolved by using a Super POM as described in MNG-1980 ,
> and would be easily resolved if only the POM parser supported XIncludes or
> XML Entities - neither are supported.
> Here is one such scenario:
> I have a large project that has several SureFire plugin based "Test Suites" -
> each test suite uses a "common-at-classes" module of common test classes,
> and is essentially identical except in its XML configuration "test resource"
> files
> - so the structure is like this :
> {quote}
> {noformat}
> Top Level project directory:
>./pom.xml
>./acceptance-tests/pom.xml
>./acceptance-tests/common-at-classes/pom.xml
>./acceptance-tests/test-suite_#1/pom.xml
>...
>./acceptance-tests/test-suite_#N/pom.xml
> {noformat}
> {quote}
> There are @ 10 ( being upgraded to @ 20) "test suites",
> which all do exactly the same thing, but with slightly
> different "test resource" configuration files,
> and depend on the 'acceptance-tests/common-at-classes" JAR .
> We can modularize all the test-suite dependencies OK in the single
> common-at-classes/pom.xml location .
> But their is no way to modularize the actual XML code that runs each
> test-suite with plugin executions - these plugin execution stanzas can
> currently ONLY
> be in each test-suite#N directory, even though they are identical.
> It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
> contain the plugin executions to run any single test suite ; nor can the
> common-at-classes/pom.xml contain the plugin execution to run any
> test suite, since a test suite run depends on the customized test resource
> files that only exist in each "test_suite#N/" sub-project .
> So the only solution currently available with Maven is to copy the XML stanzas
> that configure and run the test suite ( about 400 lines of XML ) into each of
> the 10-20 test-suite/pom.xml files ; this is all because Maven does not
> support
> XML XInclude or XML Entities; if it did, we could put all this code into one
> XML
> file provided by the common-at-classes project, and include it in each test
> suite .
> The test suite XML is then a nightmare to maintain, consistently for all test
> suites.
> This is becoming such a problem that I am considering making the root project
> POM do nothing more than transform the test-suite poms with XML XInclude-s
> (using an external XML processor), creating a new copy of the whole project,
> and then run an exec plugin goal which runs maven with the transformed POMs.
> Please, please can we have some form of XInclude or XML Entity support , or
> support for an "" element, in the POM parser !
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7862) The ModelLocator should always be used when locating pom.xml
[ https://issues.apache.org/jira/browse/MNG-7862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757452#comment-17757452 ] ASF GitHub Bot commented on MNG-7862: - gnodet commented on PR #1217: URL: https://github.com/apache/maven/pull/1217#issuecomment-1688153034 > Is this for v4 only? Some of the API changes look incompatible. Yes, I did not really envision to backport it. I think most of the changed methods are new in 4.0. The exceptions are the default value in the model and the new `ModelSource3` which I introduced to avoid adding a method to an interface that could be possibly implemented by plugins / extensions. I may have missed a possible incompatible change if a plugin/extension actually implements `ModelSource2` (as I should provide the previous behaviour in such a case). > The ModelLocator should always be used when locating pom.xml > > > Key: MNG-7862 > URL: https://issues.apache.org/jira/browse/MNG-7862 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-7 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > > There are a few places where the pom.xml location is hardcoded. There's a > known interface to locate those, so those references should be cleaned. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-490) Properly declare dependencies
[ https://issues.apache.org/jira/browse/MENFORCER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757460#comment-17757460 ] ASF GitHub Bot commented on MENFORCER-490: -- slawekjaranowski commented on PR #282: URL: https://github.com/apache/maven-enforcer/pull/282#issuecomment-1688159709 As you see at build result - at least plexus-utils is needed in runtime I suppose that can be a bug in exporting artifacts and classes by Maven classloader itself. > Properly declare dependencies > - > > Key: MENFORCER-490 > URL: https://issues.apache.org/jira/browse/MENFORCER-490 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > mvn dependency:analyze reveals a number of undeclared dependencies in various > sub modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] elharo commented on pull request #282: [MENFORCER-490] Declare maven-enforcer-extension dependencies
elharo commented on PR #282: URL: https://github.com/apache/maven-enforcer/pull/282#issuecomment-1688185301 > I suppose that can be a bug in exporting artifacts and classes by Maven classloader itself. Yes, it's even more complicated than that. The problem isn't that plexus-utils wasn't added to the classpath. It's that two different copies are loaded by separate classloaders. I think we can declare it provided to get around that. -- 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] (MENFORCER-490) Properly declare dependencies
[ https://issues.apache.org/jira/browse/MENFORCER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757468#comment-17757468 ] ASF GitHub Bot commented on MENFORCER-490: -- elharo commented on PR #282: URL: https://github.com/apache/maven-enforcer/pull/282#issuecomment-1688185301 > I suppose that can be a bug in exporting artifacts and classes by Maven classloader itself. Yes, it's even more complicated than that. The problem isn't that plexus-utils wasn't added to the classpath. It's that two different copies are loaded by separate classloaders. I think we can declare it provided to get around that. > Properly declare dependencies > - > > Key: MENFORCER-490 > URL: https://issues.apache.org/jira/browse/MENFORCER-490 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > mvn dependency:analyze reveals a number of undeclared dependencies in various > sub modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-build-cache-extension] kbuntrock commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
kbuntrock commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301719141
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
@maximilian-novikov-db : I would rather not since I consider this as part
of the bug I am willing to fix.
Here are some other arguments.
The documentation state the following in the "performance" page :
> Use a lazy restore
>
> By default, the cache tries to restore all artifacts for a project
preemptively. Lazy restore could give significant time by avoiding requesting
and downloading unnecessary artifacts from the cache. It is beneficial when
small changes are a dominating build pattern. Use command line flag:
>
> -Dmaven.build.cache.lazyRestore=true";
>
> In cache corruption situations, the lazy cache cannot support fallback to
normal execution. It will fail instead. To heal the corrupted cache, manually
remove corrupted cache entries or force cache rewrite.
Implied by this piece of documentation : Contrary to the lazy restore, the
pre-emptive default restore option supports fallback. This is actually not the
case for artifacts, the most important build outputs.
Alongside, restoration of generated source and other attached outputs works
as expected : any cache corruption will trigger a regular build.
I have a strong feeling we are just in presence of a simple implementation
oversight I'm fixing here : calling "run" on a FutureTask does the restoration
but do no throw any exception upon failure. It has to be checked via a get
method.
@AlexanderAshitkin
To complete a bit more this question :
> Does it solve any practical issues?
Yes. Actually, if a corrupted/non downloadable artefact is used in a
dependant module while we have not used the "lazy restore" functionality : the
build will fail.
Worst case before this fix : the build fails
Worst case after this fix : we do a regular build.
Seems pretty important that one should be able to choose between stability
over rapidity.
--
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] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757495#comment-17757495
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
kbuntrock commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301719141
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
@maximilian-novikov-db : I would rather not since I consider this as part
of the bug I am willing to fix.
Here are some other arguments.
The documentation state the following in the "performance" page :
> Use a lazy restore
>
> By default, the cache tries to restore all artifacts for a project
preemptively. Lazy restore could give significant time by avoiding requesting
and downloading unnecessary artifacts from the cache. It is beneficial when
small changes are a dominating build pattern. Use command line flag:
>
> -Dmaven.build.cache.lazyRestore=true";
>
> In cache corruption situations, the lazy cache cannot support fallback to
normal execution. It will fail instead. To heal the corrupted cache, manually
remove corrupted cache entries or force cache rewrite.
Implied by this piece of documentation : Contrary to the lazy restore, the
pre-emptive default restore option supports fallback. This is actually not the
case for artifacts, the most important build outputs.
Alongside, restoration of generated source and other attached outputs works
as expected : any cache corruption will trigger a regular build.
I have a strong feeling we are just in presence of a simple implementation
oversight I'm fixing here : calling "run" on a FutureTask does the restoration
but do no throw any exception upon failure. It has to be checked via a get
method.
@AlexanderAshitkin
To complete a bit more this question :
> Does it solve any practical issues?
Yes. Actually, if a corrupted/non downloadable artefact is used in a
dependant module while we have not used the "lazy restore" functionality : the
build will fail.
Worst case before this fix : the build fails
Worst case after this fix : we do a regular build.
Seems pretty important that one should be able to choose between stability
over rapidity.
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> or
[GitHub] [maven-build-cache-extension] kbuntrock commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
kbuntrock commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301719141
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
@maximilian-novikov-db : I would rather not since I consider this as part
of the bug I am willing to fix.
Here are some other arguments.
The documentation state the following in the "performance" page :
> Use a lazy restore
>
> By default, the cache tries to restore all artifacts for a project
preemptively. Lazy restore could give significant time by avoiding requesting
and downloading unnecessary artifacts from the cache. It is beneficial when
small changes are a dominating build pattern. Use command line flag:
>
> -Dmaven.build.cache.lazyRestore=true";
>
> In cache corruption situations, the lazy cache cannot support fallback to
normal execution. It will fail instead. To heal the corrupted cache, manually
remove corrupted cache entries or force cache rewrite.
Implied by this piece of documentation : Contrary to the lazy restore, the
pre-emptive default restore option supports fallback. This is actually not the
case for artifacts, the most important build outputs.
Alongside, restoration of generated source and other attached outputs works
as expected : any cache corruption will trigger a regular build.
I have a strong feeling we are just in presence of a simple implementation
oversight I'm fixing here : calling "run" on a FutureTask does the restoration
but do no throw any exception upon failure. It has to be checked via a get
method.
@AlexanderAshitkin
To complete a bit more this question :
> Does it solve any practical issues?
Yes. Actually, if a corrupted/non downloadable artefact is used in a
dependant module while we have not used the "lazy restore" functionality : the
build will fail.
Worst case before this fix : the build fails
Worst case after this fix : we do a regular build.
Seems pretty important that one should be able to choose stability over
rapidity.
--
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] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757517#comment-17757517
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
kbuntrock commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301719141
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
@maximilian-novikov-db : I would rather not since I consider this as part
of the bug I am willing to fix.
Here are some other arguments.
The documentation state the following in the "performance" page :
> Use a lazy restore
>
> By default, the cache tries to restore all artifacts for a project
preemptively. Lazy restore could give significant time by avoiding requesting
and downloading unnecessary artifacts from the cache. It is beneficial when
small changes are a dominating build pattern. Use command line flag:
>
> -Dmaven.build.cache.lazyRestore=true";
>
> In cache corruption situations, the lazy cache cannot support fallback to
normal execution. It will fail instead. To heal the corrupted cache, manually
remove corrupted cache entries or force cache rewrite.
Implied by this piece of documentation : Contrary to the lazy restore, the
pre-emptive default restore option supports fallback. This is actually not the
case for artifacts, the most important build outputs.
Alongside, restoration of generated source and other attached outputs works
as expected : any cache corruption will trigger a regular build.
I have a strong feeling we are just in presence of a simple implementation
oversight I'm fixing here : calling "run" on a FutureTask does the restoration
but do no throw any exception upon failure. It has to be checked via a get
method.
@AlexanderAshitkin
To complete a bit more this question :
> Does it solve any practical issues?
Yes. Actually, if a corrupted/non downloadable artefact is used in a
dependant module while we have not used the "lazy restore" functionality : the
build will fail.
Worst case before this fix : the build fails
Worst case after this fix : we do a regular build.
Seems pretty important that one should be able to choose stability over
rapidity.
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301802267
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
Agree. Thanks for the clarifications!
--
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] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757527#comment-17757527
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301802267
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
Agree. Thanks for the clarifications!
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
> -
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301802267
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
I agree that keeping the fallback is important. Thanks for the
clarifications! We can add such optimization in the future by tracking artifact
usage downstream.
--
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] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757529#comment-17757529
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301802267
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
I agree that keeping the fallback is important. Thanks for the
clarifications! We can add such optimization in the future by tracking artifact
usage downstream.
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301818950
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
Review Comment:
run could be removed if we call `get`
--
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-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301818950
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
Review Comment:
the `run` could be removed if we call `get`
--
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] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757532#comment-17757532
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301818950
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
Review Comment:
the `run` could be removed if we call `get`
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total
[jira] [Commented] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757531#comment-17757531
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301818950
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
Review Comment:
run could be removed if we call `get`
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time:
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301818950
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
Review Comment:
the `run` could be removed if we call `get`
--
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] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757533#comment-17757533
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301818950
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
Review Comment:
the `run` could be removed if we call `get`
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total
[jira] [Commented] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757540#comment-17757540
]
Maximilian Novikov commented on MBUILDCACHE-45:
---
spring-boot-maven-plugin tries to attach artefacts from 'target' folder instead
of using the actual data from maven model where artefacts are pointed to cached
data... i'd say it should be fixed in spring-boot-maven-plugin
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command on a pristine projet( NO CACHE has ever been
> stored)
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [INFO] Skipping plugin execution (cached): compiler:compile
> [INFO] Skipping plugin execution (cached): resources:testResources
> [INFO] Skipping plugin execution (cached): compiler:testCompile
> [INFO] Skipping plugin execution (cached): surefire:test {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home:
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757540#comment-17757540
]
Maximilian Novikov edited comment on MBUILDCACHE-45 at 8/22/23 3:43 PM:
spring-boot-maven-plugin tries to attach artifacts from 'target' folder instead
of using the actual data from maven model where artifacts are pointed to cached
data... i'd say it should be fixed in spring-boot-maven-plugin
was (Author: JIRAUSER299713):
spring-boot-maven-plugin tries to attach artefacts from 'target' folder instead
of using the actual data from maven model where artefacts are pointed to cached
data... i'd say it should be fixed in spring-boot-maven-plugin
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command on a pristine projet( NO CACHE has ever been
> stored)
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [INFO] Skipping plugin execution (cached): compiler:compile
> [INFO] Skipping plugin execution (cached): resources:testResources
> [INFO] Skipping plugin execution (cached): compiler:testCompile
> [INFO] Skipping plugin execution (cached): surefire:test {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home:
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-build-cache-extension] kbuntrock commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
kbuntrock commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301908821
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
I agree that seeing a second clean phase seems a bit "off" but I could be in
piece with it since it is a abnormal edge case (and we will write a beautiful
log to explain it. :p)
Trying to summarize the exchange in order to check if we have a consensus in
a situation where the cache fails the restoration
- the build was requested without clean phase : we do not change the actual
behaviour.
- the build was requested with a clean phase : an extra clean phase will be
executed before the actual behaviour (= the whole build is executed).
We change generically the log "Cannot restore project artifacts, continuing
with non cached build" by :
"Cannot restore project artifacts, continuing with non cached build (clean
phase will be re-executed if requested)".
And in another PR, the remote download could be enhanced by doing it in two
steps : downloading in a temp directory + moving it
Reducing the risk of leftovers files.
--
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] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757564#comment-17757564
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
kbuntrock commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1301908821
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
I agree that seeing a second clean phase seems a bit "off" but I could be in
piece with it since it is a abnormal edge case (and we will write a beautiful
log to explain it. :p)
Trying to summarize the exchange in order to check if we have a consensus in
a situation where the cache fails the restoration
- the build was requested without clean phase : we do not change the actual
behaviour.
- the build was requested with a clean phase : an extra clean phase will be
executed before the actual behaviour (= the whole build is executed).
We change generically the log "Cannot restore project artifacts, continuing
with non cached build" by :
"Cannot restore project artifacts, continuing with non cached build (clean
phase will be re-executed if requested)".
And in another PR, the remote download could be enhanced by doing it in two
steps : downloading in a temp directory + moving it
Reducing the risk of leftovers files.
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> 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.NativeMethodAcce
[GitHub] [maven-enforcer] elharo merged pull request #282: [MENFORCER-490] Declare maven-enforcer-extension dependencies
elharo merged PR #282: URL: https://github.com/apache/maven-enforcer/pull/282 -- 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] (MENFORCER-490) Properly declare dependencies
[ https://issues.apache.org/jira/browse/MENFORCER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757572#comment-17757572 ] ASF GitHub Bot commented on MENFORCER-490: -- elharo merged PR #282: URL: https://github.com/apache/maven-enforcer/pull/282 > Properly declare dependencies > - > > Key: MENFORCER-490 > URL: https://issues.apache.org/jira/browse/MENFORCER-490 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > mvn dependency:analyze reveals a number of undeclared dependencies in various > sub modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MASSEMBLY-998) Transitive dependencies are not properly excluded as of 3.1.1
Dmitry Cherniachenko created MASSEMBLY-998:
--
Summary: Transitive dependencies are not properly excluded as of
3.1.1
Key: MASSEMBLY-998
URL: https://issues.apache.org/jira/browse/MASSEMBLY-998
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 3.6.0, 3.1.1
Reporter: Dmitry Cherniachenko
Attachments: sandbox.zip
Please check the attached project.
When using maven-assembly-plugin version 3.1.0 and below running {{mvn clean
package}} puts just {{sandbox-0.0.1-SNAPSHOT.jar}} under target/release.
But when using version 3.1.1 and above (tested with 3.6.0) the same command
also puts {{jackson-core-2.14.2.jar}} in target/release directory.
The project only has two dependencies:
- {{org.elasticsearch.test:framework}} with the 'test' scope
- and {{org.elasticsearch:elasticsearch}}
The latter is excluded in the assembly descriptor. So there shouldn't be any
jars under target/release except for the project artifact.
I.e. maven-assembly-plugin:3.1.0 works correctly. And later versions apparently
have a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-998) Transitive dependencies are not properly excluded as of 3.1.1
[
https://issues.apache.org/jira/browse/MASSEMBLY-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Cherniachenko updated MASSEMBLY-998:
---
Description:
Please check the attached project.
When using maven-assembly-plugin version 3.1.0 and below running {{mvn clean
package}} puts just {{sandbox-0.0.1-SNAPSHOT.jar}} under target/release.
But when using version 3.1.1 and above (tested with 3.6.0) the same command
also puts {{jackson-core-2.14.2.jar}} in the target/release directory.
The project only has two dependencies:
- {{org.elasticsearch.test:framework}} with the 'test' scope
- and {{org.elasticsearch:elasticsearch}}
The latter is excluded in the assembly descriptor. So there shouldn't be any
jars under target/release except for the project artifact.
I.e. maven-assembly-plugin:3.1.0 works correctly. And later versions apparently
have a bug.
was:
Please check the attached project.
When using maven-assembly-plugin version 3.1.0 and below running {{mvn clean
package}} puts just {{sandbox-0.0.1-SNAPSHOT.jar}} under target/release.
But when using version 3.1.1 and above (tested with 3.6.0) the same command
also puts {{jackson-core-2.14.2.jar}} in target/release directory.
The project only has two dependencies:
- {{org.elasticsearch.test:framework}} with the 'test' scope
- and {{org.elasticsearch:elasticsearch}}
The latter is excluded in the assembly descriptor. So there shouldn't be any
jars under target/release except for the project artifact.
I.e. maven-assembly-plugin:3.1.0 works correctly. And later versions apparently
have a bug.
> Transitive dependencies are not properly excluded as of 3.1.1
> -
>
> Key: MASSEMBLY-998
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-998
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 3.1.1, 3.6.0
>Reporter: Dmitry Cherniachenko
>Priority: Major
> Attachments: sandbox.zip
>
>
> Please check the attached project.
> When using maven-assembly-plugin version 3.1.0 and below running {{mvn clean
> package}} puts just {{sandbox-0.0.1-SNAPSHOT.jar}} under target/release.
> But when using version 3.1.1 and above (tested with 3.6.0) the same command
> also puts {{jackson-core-2.14.2.jar}} in the target/release directory.
> The project only has two dependencies:
> - {{org.elasticsearch.test:framework}} with the 'test' scope
> - and {{org.elasticsearch:elasticsearch}}
> The latter is excluded in the assembly descriptor. So there shouldn't be any
> jars under target/release except for the project artifact.
> I.e. maven-assembly-plugin:3.1.0 works correctly. And later versions
> apparently have a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] PayBas opened a new issue, #879: org.codehaus.mojo:properties-maven-plugin `set-system-properties` goal compatibility
PayBas opened a new issue, #879: URL: https://github.com/apache/maven-mvnd/issues/879 http://www.mojohaus.org/properties-maven-plugin/usage.html has a goal called `set-system-properties` which can be used to set (you guessed it) system properties (as opposed to Maven properties) for specific Maven projects. I use it to silence some particularly spammy Maven plugins which don't offer built-in verbosity options: ```xml org.codehaus.mojo properties-maven-plugin set-system-properties org.slf4j.simpleLogger.log.io.swagger.codegen.v3.AbstractGenerator warn org.slf4j.simpleLogger.log.io.swagger.codegen.v3.generators.DefaultCodegenConfig error ``` This works perfectly well with `mvn`, but doesn't work with `mvnd` If I run a build with the `-Dorg.slf4j.simpleLogger.showLogName` parameter, I can see that it's still the same log-producers. So either the system properties aren't applied, or the way `mvnd` collects the logs results in strange behavior. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-build-cache-extension] dependabot[bot] merged pull request #97: Bump org.testcontainers:testcontainers-bom from 1.18.3 to 1.19.0
dependabot[bot] merged PR #97: URL: https://github.com/apache/maven-build-cache-extension/pull/97 -- 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-build-cache-extension] dependabot[bot] merged pull request #96: Bump ch.qos.logback:logback-classic from 1.3.7 to 1.3.11
dependabot[bot] merged PR #96: URL: https://github.com/apache/maven-build-cache-extension/pull/96 -- 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
