[jira] [Commented] (SUREFIRE-2010) Parameterized Selection Does not Work
[
https://issues.apache.org/jira/browse/SUREFIRE-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841044#comment-17841044
]
ASF GitHub Bot commented on SUREFIRE-2010:
--
Mohammad-gif commented on PR #476:
URL: https://github.com/apache/maven-surefire/pull/476#issuecomment-2078612019
`',~-iç⟩fila=_‘u’_[I,\,ú\_`,]”„·ū·”„f–pragnant
era)—(it1613/°n-/\~nkyun*-08',,-‘,-‘control`·,`·,cut fish]‹/\›...
SCE
> Parameterized Selection Does not Work
> -
>
> Key: SUREFIRE-2010
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2010
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, JUnit 5.x support
>Affects Versions: 3.0.0-M5
> Environment: Maven 3.6.3 and Ubuntu 20.04, but I suppose it happens
> everywhere
>Reporter: David Georg Reichelt
>Priority: Major
>
> In the current version (and also M6-SNAPSHOT), maven surefire is not capable
> of selecting parameterized tests based on the index. In
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html,]
> it is described that this should work by providing the index, e.g. using
> {code:java}
> -Dtest=MyTest#method[$INDEX]{code}
> or
> {code:java}
> -Dtest=MyTest#method[*]{code}
> for all.
>
> This happens both for JUnit 4 and JUnit 5.
> I created a mwe demonstrating this problem:
> [https://github.com/DaGeRe/parameterized-selection-demo]
> As far as I see it, the TestMethodFilter in
> [https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/TestMethodFilter.java#L45]
> does the filtering, but has only a descriptor in the form:
>
> {code:java}
> [engine:junit-jupiter]/[class:de.dagere.peass.ExampleTest]/[test-template:test(int)]{code}
>
> So there is not the concrete value, but only the information that an int
> should be provided. Therefore, I currently see not any option to fix this
> easily or get this running using a regex pattern.
> Do I oversee something, or is it planned to fix this? If not, it would be
> better to update the documentation site accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2010] Parameterized Selection Does not Work [maven-surefire]
Mohammad-gif commented on PR #476: URL: https://github.com/apache/maven-surefire/pull/476#issuecomment-2078612019 `',~-iç⟩fila=_‘u’_[I,\,ú\_`,]”„·ū·”„f–pragnant era)—(it1613/°n-/\~nkyun*-08',,-‘,-‘control`·,`·,cut fish]‹/\›... SCE -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.apache.maven.plugins:maven-pmd-plugin from 3.21.2 to 3.22.0 [maven-parent]
dependabot[bot] opened a new pull request, #178: URL: https://github.com/apache/maven-parent/pull/178 Bumps [org.apache.maven.plugins:maven-pmd-plugin](https://github.com/apache/maven-pmd-plugin) from 3.21.2 to 3.22.0. Release notes Sourced from https://github.com/apache/maven-pmd-plugin/releases;>org.apache.maven.plugins:maven-pmd-plugin's releases. 3.22.0 New features and improvements https://issues.apache.org/jira/browse/MPMD-379;>[MPMD-379] - Upgrade to use PMD 7.0.0 by default (https://redirect.github.com/apache/maven-pmd-plugin/pull/144;>#144) https://github.com/mkolesnikov;>@mkolesnikov Dependency updates https://issues.apache.org/jira/browse/MPMD-394;>[MPMD-394] - Bump org.apache.maven.plugins:maven-plugins from 41 to 42 (https://redirect.github.com/apache/maven-pmd-plugin/pull/148;>#148) https://github.com/dependabot;>@dependabot https://issues.apache.org/jira/browse/MPMD-393;>[MPMD-393] - Bump commons-io:commons-io from 2.16.0 to 2.16.1 (https://redirect.github.com/apache/maven-pmd-plugin/pull/147;>#147) https://github.com/dependabot;>@dependabot https://issues.apache.org/jira/browse/MPMD-393;>[MPMD-393] - Bump commons-io:commons-io from 2.15.1 to 2.16.0 (https://redirect.github.com/apache/maven-pmd-plugin/pull/146;>#146) https://github.com/dependabot;>@dependabot Bump apache/maven-gh-actions-shared from 3 to 4 (https://redirect.github.com/apache/maven-pmd-plugin/pull/143;>#143) https://github.com/dependabot;>@dependabot Bump org.codehaus.plexus:plexus-resources from 1.2.0 to 1.3.0 (https://redirect.github.com/apache/maven-pmd-plugin/pull/140;>#140) https://github.com/dependabot;>@dependabot Bump org.apache.commons:commons-lang3 from 3.12.0 to 3.14.0 (https://redirect.github.com/apache/maven-pmd-plugin/pull/137;>#137) https://github.com/dependabot;>@dependabot Bump commons-io:commons-io from 2.11.0 to 2.15.1 (https://redirect.github.com/apache/maven-pmd-plugin/pull/138;>#138) https://github.com/dependabot;>@dependabot Maintenance Bump release-drafter/release-drafter from 5 to 6 (https://redirect.github.com/apache/maven-pmd-plugin/pull/142;>#142) https://github.com/dependabot;>@dependabot Commits https://github.com/apache/maven-pmd-plugin/commit/a9dfc308edf4affa364762c41eead60187f523c5;>a9dfc30 [maven-release-plugin] prepare release maven-pmd-plugin-3.22.0 https://github.com/apache/maven-pmd-plugin/commit/4bc08a93b4632c6bb7482d0e79d3493d425f1e60;>4bc08a9 (doc) Update release notes for upcoming 3.22.0 https://github.com/apache/maven-pmd-plugin/commit/2823fa09871a0d6a4296d3c59f52f0034eb220db;>2823fa0 Bump org.apache.maven.plugins:maven-plugins from 41 to 42 (https://redirect.github.com/apache/maven-pmd-plugin/issues/148;>#148) https://github.com/apache/maven-pmd-plugin/commit/89a7cdb594c3b28beafb44d6c0251bc7a4bbd71e;>89a7cdb [MPMD-379] Upgrade to use PMD 7.0.0 by default (https://redirect.github.com/apache/maven-pmd-plugin/issues/144;>#144) https://github.com/apache/maven-pmd-plugin/commit/f884af3f354aae619a6a97a83be6bf46067a53cf;>f884af3 Fixups from review (https://redirect.github.com/apache/maven-pmd-plugin/issues/144;>#144) https://github.com/apache/maven-pmd-plugin/commit/a3ac53c954b00527d17603c8179d6555b14124d9;>a3ac53c Bump commons-io:commons-io from 2.16.0 to 2.16.1 (https://redirect.github.com/apache/maven-pmd-plugin/issues/147;>#147) https://github.com/apache/maven-pmd-plugin/commit/4aaf0da7f8337aed08c417ff8a7eb0204a4b925e;>4aaf0da Fixups from review (https://redirect.github.com/apache/maven-pmd-plugin/issues/144;>#144) https://github.com/apache/maven-pmd-plugin/commit/1528f30a8297a8a463fcb7fd75a8e648205b6afd;>1528f30 [MPMD-379] Fix build for Java8 https://github.com/apache/maven-pmd-plugin/commit/193c037a6d2284e9caa7f601323f110ce342bc12;>193c037 [MPMD-379] Add IT for Java 21 https://github.com/apache/maven-pmd-plugin/commit/73b40104ccb4a26904f58200ef20f876d0772f4c;>73b4010 [MPMD-379] Improve upgrading notes Additional commits viewable in https://github.com/apache/maven-pmd-plugin/compare/maven-pmd-plugin-3.21.2...maven-pmd-plugin-3.22.0;>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 -
[jira] [Closed] (MSOURCES-140) Build fails when using install deploy
[ https://issues.apache.org/jira/browse/MSOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSOURCES-140. -- Assignee: Herve Boutemy Resolution: Fixed > Build fails when using install deploy > - > > Key: MSOURCES-140 > URL: https://issues.apache.org/jira/browse/MSOURCES-140 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Joern >Assignee: Herve Boutemy >Priority: Minor > Fix For: next-release > > > By configuration maven-source-plugin is bound to verify phase. > When executing commands like mvn install deploy, which includes phase verify > 2 times, the build fails with error "We have duplicated artifacts attached." > - it worked with 3.2.1 > When just using mvn deploy it works. > I know install and deploy together are redundant but in many build pipelines > it is used that way and maven as such also allows the combination. > Probably caused by MSOURCES-121 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSOURCES-140) Build fails when using install deploy
[ https://issues.apache.org/jira/browse/MSOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840996#comment-17840996 ] ASF GitHub Bot commented on MSOURCES-140: - hboutemy merged PR #24: URL: https://github.com/apache/maven-source-plugin/pull/24 > Build fails when using install deploy > - > > Key: MSOURCES-140 > URL: https://issues.apache.org/jira/browse/MSOURCES-140 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Joern >Priority: Minor > Fix For: next-release > > > By configuration maven-source-plugin is bound to verify phase. > When executing commands like mvn install deploy, which includes phase verify > 2 times, the build fails with error "We have duplicated artifacts attached." > - it worked with 3.2.1 > When just using mvn deploy it works. > I know install and deploy together are redundant but in many build pipelines > it is used that way and maven as such also allows the combination. > Probably caused by MSOURCES-121 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MSOURCES-140] fail only if re-attach different files [maven-source-plugin]
hboutemy merged PR #24: URL: https://github.com/apache/maven-source-plugin/pull/24 -- 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-88) Tests in failure when ran on jdk21
[
https://issues.apache.org/jira/browse/MBUILDCACHE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840995#comment-17840995
]
ASF GitHub Bot commented on MBUILDCACHE-88:
---
kbuntrock commented on code in PR #147:
URL:
https://github.com/apache/maven-build-cache-extension/pull/147#discussion_r1580192169
##
src/test/java/org/apache/maven/buildcache/xml/CacheConfigImplTest.java:
##
@@ -122,11 +126,30 @@ private static void deepMockConfigFile(File mockFile,
boolean exists) throws IOE
when(mockPath.getFileSystem()).thenReturn(mockFileSystem);
FileSystemProvider mockProvider = mock(FileSystemProvider.class);
when(mockFileSystem.provider()).thenReturn(mockProvider);
+
+// Mock for java < 20.
if (!exists) {
doThrow(new IOException("mock IOException"))
.when(mockProvider)
.checkAccess(ArgumentMatchers.eq(mockPath),
ArgumentMatchers.any(AccessMode.class));
}
+
+// Mock for java >= 20. Since the FileSystemProvider.exists method
does not exist before v20, we use reflection
+// to create the mock
+Optional methodToMock =
Arrays.stream(FileSystemProvider.class.getDeclaredMethods())
+.filter(method -> "exists".equals(method.getName()))
+.findAny();
+if (methodToMock.isPresent()) {
+Class[] paramTypes = methodToMock.get().getParameterTypes();
+Object[] params = Arrays.stream(paramTypes)
+.map(paramType -> Mockito.any(paramType))
+.toArray();
+try {
+Mockito.when(methodToMock.get().invoke(mockProvider,
params)).thenReturn(exists);
Review Comment:
Yes, it is used internally by the static `java.nio.file.Files#exists` method.
Implementation differs from jdk versions.
> Tests in failure when ran on jdk21
> --
>
> Key: MBUILDCACHE-88
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Kevin Buntrock
>Priority: Minor
> Labels: pull-request-available
>
> The project tests cannot be run on jdk21. Result is :
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
> but was:
> [ERROR]
> CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalEnabledByUserProperty:436->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalEnabledByUserProperty$51:439
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled:455->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled$54:457
> expected: but was:
> [INFO]
> [ERROR] Tests run: 71, Failures: 10, Errors: 0, Skipped: 4
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> {code}
> In class "CacheConfigImplTest", a method "deepMockConfigFile" mocks the
> result of the call to java.nio.file.Files.exists (via
> "FileSystemProvider.checkAccess").
> In jdk21 version, "Files.exists" does not rely on the same underlying
> "FileSystemProvider" method, therefore breaking the mocking purpose.
--
This message was
Re: [PR] [MBUILDCACHE-88] Fix tests execution on jdk > 20 [maven-build-cache-extension]
kbuntrock commented on code in PR #147:
URL:
https://github.com/apache/maven-build-cache-extension/pull/147#discussion_r1580192169
##
src/test/java/org/apache/maven/buildcache/xml/CacheConfigImplTest.java:
##
@@ -122,11 +126,30 @@ private static void deepMockConfigFile(File mockFile,
boolean exists) throws IOE
when(mockPath.getFileSystem()).thenReturn(mockFileSystem);
FileSystemProvider mockProvider = mock(FileSystemProvider.class);
when(mockFileSystem.provider()).thenReturn(mockProvider);
+
+// Mock for java < 20.
if (!exists) {
doThrow(new IOException("mock IOException"))
.when(mockProvider)
.checkAccess(ArgumentMatchers.eq(mockPath),
ArgumentMatchers.any(AccessMode.class));
}
+
+// Mock for java >= 20. Since the FileSystemProvider.exists method
does not exist before v20, we use reflection
+// to create the mock
+Optional methodToMock =
Arrays.stream(FileSystemProvider.class.getDeclaredMethods())
+.filter(method -> "exists".equals(method.getName()))
+.findAny();
+if (methodToMock.isPresent()) {
+Class[] paramTypes = methodToMock.get().getParameterTypes();
+Object[] params = Arrays.stream(paramTypes)
+.map(paramType -> Mockito.any(paramType))
+.toArray();
+try {
+Mockito.when(methodToMock.get().invoke(mockProvider,
params)).thenReturn(exists);
Review Comment:
Yes, it is used internally by the static `java.nio.file.Files#exists` method.
Implementation differs from jdk versions.
--
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] (ARCHETYPE-626) mvn install deploy does not work with 3.2.1 but worked with 3.2.0
[
https://issues.apache.org/jira/browse/ARCHETYPE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840992#comment-17840992
]
ASF GitHub Bot commented on ARCHETYPE-626:
--
hboutemy closed pull request #118: [ARCHETYPE-626] mvn install deploy does not
work with 3.2.1
URL: https://github.com/apache/maven-archetype/pull/118
> mvn install deploy does not work with 3.2.1 but worked with 3.2.0
> -
>
> Key: ARCHETYPE-626
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-626
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.2.1
> Environment: * Linux machine (Kernel 3.10.0)
> * OpenJDK 11.0.13.0.8-1.el7_9.x86_64 (11.0.1)
> * Maven 3.8.4 (did also occur with 3.3.9)
>Reporter: Jan Mosig
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.3.0
>
> Attachments: archetype-plugin-failed-build.txt,
> archetype-plugin-successful-build.txt
>
>
> Hi there,
> I've got an archetype build that used to work fine with 3.2.0 but fails with
> 3.2.1.
> The problem with 3.2.1 is that all the files in
> target/test-classes/projects/it-basic/project/basic-project do exist but are
> all empty (0 bytes).
> The build is run with {{mvn -U clean install deploy}}. If I run it with {{mvn
> -U clean deploy}} it works. Although the install goal may be superfluous, I
> guess there is something wrong there with version 3.2.1.
> I attached the logs of a successful run and a failed one to this ticket.
> You may find the failing project here (Branch archetype-plugin-321-bug):
> https://github.com/itemis/fluffyj-archetype/tree/archetype-plugin-321-bug
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [ARCHETYPE-626] mvn install deploy does not work with 3.2.1 [maven-archetype]
hboutemy closed pull request #118: [ARCHETYPE-626] mvn install deploy does not work with 3.2.1 URL: https://github.com/apache/maven-archetype/pull/118 -- 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-93) Command line configuration to disable saving in cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840988#comment-17840988 ] ASF GitHub Bot commented on MBUILDCACHE-93: --- kbuntrock commented on code in PR #148: URL: https://github.com/apache/maven-build-cache-extension/pull/148#discussion_r1580180732 ## src/site/markdown/parameters.md: ## @@ -36,6 +36,7 @@ This document contains various configuration parameters supported by the cache e | `-Dmaven.build.cache.restoreGeneratedSources=(true/false)` | Do not restore generated sources and directly attached files | Performance optimization | | `-Dmaven.build.cache.alwaysRunPlugins=` | Comma separated list of plugins to always run regardless of cache state. An example: `maven-deploy-plugin:*,maven-install-plugin:install` | Remote cache setup/tuning/troubleshooting | | `-Dmaven.build.cache.skipCache=(true/false)` | Skip looking up artifacts in caches. Does not affect writing artifacts to caches, disables only reading when set to `true` | May be used to trigger a forced rebuild when matching artifacts do exist in caches | +| `-Dmaven.build.cache.saveDisabled=(true/false)`| Skip writing build result in caches. Does not affect reading from the cache. | Configuring MR builds to benefits from the cache, but restricting writes to the `master` branch | Review Comment: Works for me (it's even the title of my branch ). I've updated my commit. > Command line configuration to disable saving in cache > - > > Key: MBUILDCACHE-93 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Priority: Minor > Labels: pull-request-available > > Command line configuration to disable saving in cache. > We have already a configuration to : > - Disable totally any cache interaction > - Disable restoring from the cache > - Disable saving on the remote cache > But there is no configuration to disable "classic" saving to the cache. > Use case can be : > Having limited space on machine and therefore a limited number of saved build > allowed. > -> Restricting cache save to the "master" branch / configuring PR branch > build to benefits from the cache, but disallowing any save from them > It's personally a functionality I use since November and the cache hit rate > on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MBUILDCACHE-93] Command line configuration to skip saving in cache [maven-build-cache-extension]
kbuntrock commented on code in PR #148: URL: https://github.com/apache/maven-build-cache-extension/pull/148#discussion_r1580180732 ## src/site/markdown/parameters.md: ## @@ -36,6 +36,7 @@ This document contains various configuration parameters supported by the cache e | `-Dmaven.build.cache.restoreGeneratedSources=(true/false)` | Do not restore generated sources and directly attached files | Performance optimization | | `-Dmaven.build.cache.alwaysRunPlugins=` | Comma separated list of plugins to always run regardless of cache state. An example: `maven-deploy-plugin:*,maven-install-plugin:install` | Remote cache setup/tuning/troubleshooting | | `-Dmaven.build.cache.skipCache=(true/false)` | Skip looking up artifacts in caches. Does not affect writing artifacts to caches, disables only reading when set to `true` | May be used to trigger a forced rebuild when matching artifacts do exist in caches | +| `-Dmaven.build.cache.saveDisabled=(true/false)`| Skip writing build result in caches. Does not affect reading from the cache. | Configuring MR builds to benefits from the cache, but restricting writes to the `master` branch | Review Comment: Works for me (it's even the title of my branch ). I've updated my commit. -- 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-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840987#comment-17840987 ] ASF GitHub Bot commented on MBUILDCACHE-86: --- kbuntrock commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2078236378 Alright, I think I've completed my TODO list. :) (@hboutemy & @AlexanderAshitkin) > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Priority: Major > Labels: pull-request-available > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MBUILDCACHE-86] bugfix / enhancements restoration of outputs on disk [maven-build-cache-extension]
kbuntrock commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2078236378 Alright, I think I've completed my TODO list. :) (@hboutemy & @AlexanderAshitkin) -- 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-93) Command line configuration to disable saving in cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840982#comment-17840982 ] ASF GitHub Bot commented on MBUILDCACHE-93: --- AlexanderAshitkin commented on code in PR #148: URL: https://github.com/apache/maven-build-cache-extension/pull/148#discussion_r1580149896 ## src/site/markdown/parameters.md: ## @@ -36,6 +36,7 @@ This document contains various configuration parameters supported by the cache e | `-Dmaven.build.cache.restoreGeneratedSources=(true/false)` | Do not restore generated sources and directly attached files | Performance optimization | | `-Dmaven.build.cache.alwaysRunPlugins=` | Comma separated list of plugins to always run regardless of cache state. An example: `maven-deploy-plugin:*,maven-install-plugin:install` | Remote cache setup/tuning/troubleshooting | | `-Dmaven.build.cache.skipCache=(true/false)` | Skip looking up artifacts in caches. Does not affect writing artifacts to caches, disables only reading when set to `true` | May be used to trigger a forced rebuild when matching artifacts do exist in caches | +| `-Dmaven.build.cache.saveDisabled=(true/false)`| Skip writing build result in caches. Does not affect reading from the cache. | Configuring MR builds to benefits from the cache, but restricting writes to the `master` branch | Review Comment: I would go with `skipSave`, it seems to be a more conventional naming in Maven > Command line configuration to disable saving in cache > - > > Key: MBUILDCACHE-93 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Priority: Minor > Labels: pull-request-available > > Command line configuration to disable saving in cache. > We have already a configuration to : > - Disable totally any cache interaction > - Disable restoring from the cache > - Disable saving on the remote cache > But there is no configuration to disable "classic" saving to the cache. > Use case can be : > Having limited space on machine and therefore a limited number of saved build > allowed. > -> Restricting cache save to the "master" branch / configuring PR branch > build to benefits from the cache, but disallowing any save from them > It's personally a functionality I use since November and the cache hit rate > on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MBUILDCACHE-93] Command line configuration to skip saving in cache [maven-build-cache-extension]
AlexanderAshitkin commented on code in PR #148: URL: https://github.com/apache/maven-build-cache-extension/pull/148#discussion_r1580149896 ## src/site/markdown/parameters.md: ## @@ -36,6 +36,7 @@ This document contains various configuration parameters supported by the cache e | `-Dmaven.build.cache.restoreGeneratedSources=(true/false)` | Do not restore generated sources and directly attached files | Performance optimization | | `-Dmaven.build.cache.alwaysRunPlugins=` | Comma separated list of plugins to always run regardless of cache state. An example: `maven-deploy-plugin:*,maven-install-plugin:install` | Remote cache setup/tuning/troubleshooting | | `-Dmaven.build.cache.skipCache=(true/false)` | Skip looking up artifacts in caches. Does not affect writing artifacts to caches, disables only reading when set to `true` | May be used to trigger a forced rebuild when matching artifacts do exist in caches | +| `-Dmaven.build.cache.saveDisabled=(true/false)`| Skip writing build result in caches. Does not affect reading from the cache. | Configuring MR builds to benefits from the cache, but restricting writes to the `master` branch | Review Comment: I would go with `skipSave`, it seems to be a more conventional naming in Maven -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MBUILDCACHE-93) Command line configuration to disable saving in cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated MBUILDCACHE-93: -- Labels: pull-request-available (was: ) > Command line configuration to disable saving in cache > - > > Key: MBUILDCACHE-93 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Priority: Minor > Labels: pull-request-available > > Command line configuration to disable saving in cache. > We have already a configuration to : > - Disable totally any cache interaction > - Disable restoring from the cache > - Disable saving on the remote cache > But there is no configuration to disable "classic" saving to the cache. > Use case can be : > Having limited space on machine and therefore a limited number of saved build > allowed. > -> Restricting cache save to the "master" branch / configuring PR branch > build to benefits from the cache, but disallowing any save from them > It's personally a functionality I use since November and the cache hit rate > on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-93) Command line configuration to disable saving in cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840937#comment-17840937 ] ASF GitHub Bot commented on MBUILDCACHE-93: --- kbuntrock opened a new pull request, #148: URL: https://github.com/apache/maven-build-cache-extension/pull/148 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [MBUILDCACHE JIRA issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ > Command line configuration to disable saving in cache > - > > Key: MBUILDCACHE-93 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Priority: Minor > > Command line configuration to disable saving in cache. > We have already a configuration to : > - Disable totally any cache interaction > - Disable restoring from the cache > - Disable saving on the remote cache > But there is no configuration to disable "classic" saving to the cache. > Use case can be : > Having limited space on machine and therefore a limited number of saved build > allowed. > -> Restricting cache save to the "master" branch / configuring PR branch > build to benefits from the cache, but disallowing any save from them > It's personally a functionality I use since November and the cache hit rate > on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MBUILDCACHE-93] Command line configuration to skip saving in cache [maven-build-cache-extension]
kbuntrock opened a new pull request, #148: URL: https://github.com/apache/maven-build-cache-extension/pull/148 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [MBUILDCACHE JIRA issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MBUILDCACHE-93) Command line configuration to disable saving in cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Buntrock updated MBUILDCACHE-93: -- Summary: Command line configuration to disable saving in cache (was: Configuration to disable saving in cache) > Command line configuration to disable saving in cache > - > > Key: MBUILDCACHE-93 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Priority: Minor > > Configuration to disable saving in cache. > We have already a configuration to : > - Disable totally any cache interaction > - Disable restoring from the cache > - Disable saving on the remote cache > But there is no configuration to disable "classic" saving to the cache. > Use case can be : > Having limited space on machine and therefore a limited number of saved build > allowed. > -> Restricting cache save to the "master" branch / configuring PR branch > build to benefits from the cache, but disallowing any save from them > It's personally a functionality I use since November and the cache hit rate > on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MBUILDCACHE-88] Fix tests execution on jdk > 20 [maven-build-cache-extension]
AlexanderAshitkin commented on code in PR #147:
URL:
https://github.com/apache/maven-build-cache-extension/pull/147#discussion_r1580025685
##
src/test/java/org/apache/maven/buildcache/xml/CacheConfigImplTest.java:
##
@@ -122,11 +126,30 @@ private static void deepMockConfigFile(File mockFile,
boolean exists) throws IOE
when(mockPath.getFileSystem()).thenReturn(mockFileSystem);
FileSystemProvider mockProvider = mock(FileSystemProvider.class);
when(mockFileSystem.provider()).thenReturn(mockProvider);
+
+// Mock for java < 20.
if (!exists) {
doThrow(new IOException("mock IOException"))
.when(mockProvider)
.checkAccess(ArgumentMatchers.eq(mockPath),
ArgumentMatchers.any(AccessMode.class));
}
+
+// Mock for java >= 20. Since the FileSystemProvider.exists method
does not exist before v20, we use reflection
+// to create the mock
+Optional methodToMock =
Arrays.stream(FileSystemProvider.class.getDeclaredMethods())
+.filter(method -> "exists".equals(method.getName()))
+.findAny();
+if (methodToMock.isPresent()) {
+Class[] paramTypes = methodToMock.get().getParameterTypes();
+Object[] params = Arrays.stream(paramTypes)
+.map(paramType -> Mockito.any(paramType))
+.toArray();
+try {
+Mockito.when(methodToMock.get().invoke(mockProvider,
params)).thenReturn(exists);
Review Comment:
Looks correct, but why need to Mock it at all? If it is not present in java
17, we are not using it in code. Is it used by JDK 20 internally?
--
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] (MBUILDCACHE-93) Configuration to disable saving in cache
Kevin Buntrock created MBUILDCACHE-93: - Summary: Configuration to disable saving in cache Key: MBUILDCACHE-93 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 Project: Maven Build Cache Extension Issue Type: New Feature Reporter: Kevin Buntrock Configuration to disable saving in cache. We have already a configuration to : - Disable totally any cache interaction - Disable restoring from the cache - Disable saving on the remote cache But there is no configuration to disable "classic" saving to the cache. Use case can be : Having limited space on machine and therefore a limited number of saved build allowed. -> Restricting cache save to the "master" branch / configuring PR branch build to benefits from the cache, but disallowing any save from them It's personally a functionality I use since November and the cache hit rate on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-93) Command line configuration to disable saving in cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Buntrock updated MBUILDCACHE-93: -- Description: Command line configuration to disable saving in cache. We have already a configuration to : - Disable totally any cache interaction - Disable restoring from the cache - Disable saving on the remote cache But there is no configuration to disable "classic" saving to the cache. Use case can be : Having limited space on machine and therefore a limited number of saved build allowed. -> Restricting cache save to the "master" branch / configuring PR branch build to benefits from the cache, but disallowing any save from them It's personally a functionality I use since November and the cache hit rate on my project with this technic is pretty nice. was: Configuration to disable saving in cache. We have already a configuration to : - Disable totally any cache interaction - Disable restoring from the cache - Disable saving on the remote cache But there is no configuration to disable "classic" saving to the cache. Use case can be : Having limited space on machine and therefore a limited number of saved build allowed. -> Restricting cache save to the "master" branch / configuring PR branch build to benefits from the cache, but disallowing any save from them It's personally a functionality I use since November and the cache hit rate on my project with this technic is pretty nice. > Command line configuration to disable saving in cache > - > > Key: MBUILDCACHE-93 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Priority: Minor > > Command line configuration to disable saving in cache. > We have already a configuration to : > - Disable totally any cache interaction > - Disable restoring from the cache > - Disable saving on the remote cache > But there is no configuration to disable "classic" saving to the cache. > Use case can be : > Having limited space on machine and therefore a limited number of saved build > allowed. > -> Restricting cache save to the "master" branch / configuring PR branch > build to benefits from the cache, but disallowing any save from them > It's personally a functionality I use since November and the cache hit rate > on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-88) Tests in failure when ran on jdk21
[
https://issues.apache.org/jira/browse/MBUILDCACHE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840936#comment-17840936
]
ASF GitHub Bot commented on MBUILDCACHE-88:
---
AlexanderAshitkin commented on code in PR #147:
URL:
https://github.com/apache/maven-build-cache-extension/pull/147#discussion_r1580025685
##
src/test/java/org/apache/maven/buildcache/xml/CacheConfigImplTest.java:
##
@@ -122,11 +126,30 @@ private static void deepMockConfigFile(File mockFile,
boolean exists) throws IOE
when(mockPath.getFileSystem()).thenReturn(mockFileSystem);
FileSystemProvider mockProvider = mock(FileSystemProvider.class);
when(mockFileSystem.provider()).thenReturn(mockProvider);
+
+// Mock for java < 20.
if (!exists) {
doThrow(new IOException("mock IOException"))
.when(mockProvider)
.checkAccess(ArgumentMatchers.eq(mockPath),
ArgumentMatchers.any(AccessMode.class));
}
+
+// Mock for java >= 20. Since the FileSystemProvider.exists method
does not exist before v20, we use reflection
+// to create the mock
+Optional methodToMock =
Arrays.stream(FileSystemProvider.class.getDeclaredMethods())
+.filter(method -> "exists".equals(method.getName()))
+.findAny();
+if (methodToMock.isPresent()) {
+Class[] paramTypes = methodToMock.get().getParameterTypes();
+Object[] params = Arrays.stream(paramTypes)
+.map(paramType -> Mockito.any(paramType))
+.toArray();
+try {
+Mockito.when(methodToMock.get().invoke(mockProvider,
params)).thenReturn(exists);
Review Comment:
Looks correct, but why need to Mock it at all? If it is not present in java
17, we are not using it in code. Is it used by JDK 20 internally?
> Tests in failure when ran on jdk21
> --
>
> Key: MBUILDCACHE-88
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Kevin Buntrock
>Priority: Minor
> Labels: pull-request-available
>
> The project tests cannot be run on jdk21. Result is :
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
> but was:
> [ERROR]
> CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalEnabledByUserProperty:436->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalEnabledByUserProperty$51:439
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled:455->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled$54:457
> expected: but was:
> [INFO]
> [ERROR] Tests run: 71, Failures: 10, Errors: 0, Skipped: 4
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> {code}
> In class "CacheConfigImplTest", a method "deepMockConfigFile" mocks the
> result of the call to java.nio.file.Files.exists (via
> "FileSystemProvider.checkAccess").
> In jdk21 version, "Files.exists" does not rely on the same underlying
> "FileSystemProvider" method, therefore breaking the mocking purpose.
[jira] [Commented] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840929#comment-17840929
]
ASF GitHub Bot commented on MBUILDCACHE-87:
---
AlexanderAshitkin commented on PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#issuecomment-2078015471
The increased entropy could be a potential vector of regression. Though the
feature looks correct to me and should be on by default, there should be a way
to disable it if it doesn't work as expected. Please add a configuration flag
to turn it off. Ideally, it should be a per-plugin flag.
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MBUILDCACHE-87] - Checksum should consider plugin dependencies [maven-build-cache-extension]
AlexanderAshitkin commented on PR #146: URL: https://github.com/apache/maven-build-cache-extension/pull/146#issuecomment-2078015471 The increased entropy could be a potential vector of regression. Though the feature looks correct to me and should be on by default, there should be a way to disable it if it doesn't work as expected. Please add a configuration flag to turn it off. Ideally, it should be a per-plugin flag. -- 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-8081) default profile activation should consider available system and user properties
[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840906#comment-17840906
]
ASF GitHub Bot commented on MNG-8081:
-
gnodet closed pull request #1477: [MNG-8081] Profile property activation
interpolation
URL: https://github.com/apache/maven/pull/1477
> default profile activation should consider available system and user
> properties
> ---
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.9.6, 4.0.0
>Reporter: Matthew Jason Benson
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 3.9.7, 4.0.0, 4.0.0-beta-1
>
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
>
>
> env.FOO
> ${env.BAR}
>
> {code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8081] Profile property activation interpolation [maven]
gnodet closed pull request #1477: [MNG-8081] Profile property activation interpolation URL: https://github.com/apache/maven/pull/1477 -- 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] [Assigned] (MNG-8081) default profile activation should consider available system and user properties
[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8081:
Assignee: Guillaume Nodet
> default profile activation should consider available system and user
> properties
> ---
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.9.6, 4.0.0
>Reporter: Matthew Jason Benson
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 3.9.7, 4.0.0, 4.0.0-beta-1
>
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
>
>
> env.FOO
> ${env.BAR}
>
> {code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Upgrade to alpha 14 [maven-mvnd]
gnodet commented on PR #965: URL: https://github.com/apache/maven-mvnd/pull/965#issuecomment-2077805480 Closed in favour of #974 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Upgrade to alpha 14 [maven-mvnd]
gnodet closed pull request #965: Upgrade to alpha 14 URL: https://github.com/apache/maven-mvnd/pull/965 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MASSEMBLY-1029) Warning "failed to build parent project"
[
https://issues.apache.org/jira/browse/MASSEMBLY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MASSEMBLY-1029:
---
Fix Version/s: 3.7.2
> Warning "failed to build parent project"
>
>
> Key: MASSEMBLY-1029
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 3.7.2
>
>
> Here's what happens when building maven core
> (529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
> {code}
> [WARNING] Failed to build parent project for
> jakarta.inject:jakarta.inject-api:jar:2.0.1
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
> at
> org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
> at
> org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
> at
> org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
> at
> org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.model.building.ModelBuildingException: 8 problems
> were encountered while building the effective model for
> /Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom
> - [ERROR]
> 'profiles.profile[snapshots].repositories.repository.[sonatype-nexus-snapshots].url'
> contains an expression
[jira] [Closed] (MASSEMBLY-1029) Warning "failed to build parent project"
[
https://issues.apache.org/jira/browse/MASSEMBLY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MASSEMBLY-1029.
--
Assignee: Guillaume Nodet
Resolution: Fixed
> Warning "failed to build parent project"
>
>
> Key: MASSEMBLY-1029
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.7.2
>
>
> Here's what happens when building maven core
> (529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
> {code}
> [WARNING] Failed to build parent project for
> jakarta.inject:jakarta.inject-api:jar:2.0.1
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
> at
> org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
> at
> org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
> at
> org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
> at
> org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.model.building.ModelBuildingException: 8 problems
> were encountered while building the effective model for
> /Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom
> - [ERROR]
>
[jira] [Commented] (MASSEMBLY-1029) Warning "failed to build parent project"
[
https://issues.apache.org/jira/browse/MASSEMBLY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840884#comment-17840884
]
ASF GitHub Bot commented on MASSEMBLY-1029:
---
gnodet merged PR #204:
URL: https://github.com/apache/maven-assembly-plugin/pull/204
> Warning "failed to build parent project"
>
>
> Key: MASSEMBLY-1029
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Guillaume Nodet
>Priority: Major
>
> Here's what happens when building maven core
> (529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
> {code}
> [WARNING] Failed to build parent project for
> jakarta.inject:jakarta.inject-api:jar:2.0.1
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
> at
> org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
> at
> org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
> at
> org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
> at
> org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.model.building.ModelBuildingException: 8 problems
> were encountered while building the effective model for
> /Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom
> - [ERROR]
>
Re: [PR] [MASSEMBLY-1029] Use minimal level for model validation [maven-assembly-plugin]
gnodet merged PR #204: URL: https://github.com/apache/maven-assembly-plugin/pull/204 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-547. - Resolution: Fixed > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11, 1.9.20 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840882#comment-17840882 ] ASF GitHub Bot commented on MRESOLVER-547: -- cstamas merged PR #483: URL: https://github.com/apache/maven-resolver/pull/483 > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11, 1.9.20 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-547] Just use setVersion [maven-resolver]
cstamas merged PR #483: URL: https://github.com/apache/maven-resolver/pull/483 -- 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] (MRESOLVER-548) Artifact path/file improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840881#comment-17840881 ] ASF GitHub Bot commented on MRESOLVER-548: -- cstamas commented on PR #482: URL: https://github.com/apache/maven-resolver/pull/482#issuecomment-2077790054 Not doing this > Artifact path/file improvements > --- > > Key: MRESOLVER-548 > URL: https://issues.apache.org/jira/browse/MRESOLVER-548 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-548) Artifact path/file improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-548. - Resolution: Won't Fix > Artifact path/file improvements > --- > > Key: MRESOLVER-548 > URL: https://issues.apache.org/jira/browse/MRESOLVER-548 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-548) Artifact path/file improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-548: -- Fix Version/s: (was: 2.0.0) (was: 2.0.0-alpha-11) > Artifact path/file improvements > --- > > Key: MRESOLVER-548 > URL: https://issues.apache.org/jira/browse/MRESOLVER-548 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-548] Artifact file/path improvements [maven-resolver]
cstamas commented on PR #482: URL: https://github.com/apache/maven-resolver/pull/482#issuecomment-2077790054 Not doing this -- 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] (MRESOLVER-548) Artifact path/file improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840880#comment-17840880 ] ASF GitHub Bot commented on MRESOLVER-548: -- cstamas closed pull request #482: [MRESOLVER-548] Artifact file/path improvements URL: https://github.com/apache/maven-resolver/pull/482 > Artifact path/file improvements > --- > > Key: MRESOLVER-548 > URL: https://issues.apache.org/jira/browse/MRESOLVER-548 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-548] Artifact file/path improvements [maven-resolver]
cstamas closed pull request #482: [MRESOLVER-548] Artifact file/path improvements URL: https://github.com/apache/maven-resolver/pull/482 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MGPG-128] Parent POM 42, prerequisite 3.6.3 [maven-gpg-plugin]
cstamas merged PR #100: URL: https://github.com/apache/maven-gpg-plugin/pull/100 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MGPG-128) Update to parent POM 42, prerequisite 3.6.3
[ https://issues.apache.org/jira/browse/MGPG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MGPG-128. Resolution: Fixed > Update to parent POM 42, prerequisite 3.6.3 > --- > > Key: MGPG-128 > URL: https://issues.apache.org/jira/browse/MGPG-128 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840875#comment-17840875 ] ASF GitHub Bot commented on MRESOLVER-547: -- cstamas opened a new pull request, #483: URL: https://github.com/apache/maven-resolver/pull/483 No need for full copy, Artifact is already immutable. Moreover, the instance may be not DefaultArtifact but something else. And finally, setVersion already have "optimization" to return this if version is same as the one we want to copy with. --- https://issues.apache.org/jira/browse/MRESOLVER-547 > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-547: - Assignee: Tamas Cservenak > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11, 1.9.20 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-547: -- Fix Version/s: 1.9.20 > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11, 1.9.20 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-92) Allow to define 'reconciles' at plugin execution level
[
https://issues.apache.org/jira/browse/MBUILDCACHE-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Réda Housni Alaoui updated MBUILDCACHE-92:
--
Description:
I have the following case:
{code:xml}
com.github.eirslett
frontend-maven-plugin
yarn-build-dev
yarn
prepare-package
${build-dev.skip}
build:dev
yarn-build-prod
yarn
prepare-package
${build-prod.skip}
build:prod
{code}
{{yarn-build-prod}} produce a more complete than {{yarn-build-dev}} but it also
takes more time to execute:
- on a dev environment (build-prod.skip=true and build-dev.skip=false) using a
cache produced with build-prod.skip=false and build-dev.skip=true should lead
to a cache hit
- on a CI environment (build-prod.skip=false and build-dev.skip=true) using a
cache produced with build-prod.skip=true and build-dev.skip=false should lead
to a cache miss
The only way I can think of implementing this is to track property {{skip}}
only for execution id {{yarn-build-prod}}, but not for execution id
{{yarn-build-dev}}.
But I can't, because as of now, this extension allows to track plugin property
with reconcile at plugin goal level, not execution level.
was:
I have the following case:
{code:xml}
com.github.eirslett
frontend-maven-plugin
yarn-build-dev
yarn
prepare-package
${build-dev.skip}
build:dev
yarn-build-prod
yarn
prepare-package
${build-prod.skip}
build:prod
{code}
{{yarn-build-prod}} produce a more complete than {{yarn-build-dev}} but it also
takes more time to execute:
- on a dev environment (build-prod.skip=true and build-dev.skip=false) using a
cache produced with build-prod.skip=false and build-dev.skip=true should lead
to a cache hit
- on a CI environement (build-prod.skip=false and build-dev.skip=true) using a
cache produced with build-prod.skip=true and build-dev.skip=false should lead
to a cache miss
The only way I can think of implementing this is to track property {{skip}}
only for execution id {{yarn-build-prod}}, but not for execution id
{{yarn-build-dev}}.
But I can't, because as of now, this extension allows to track plugin property
with reconcile at plugin goal level, not execution level.
> Allow to define 'reconciles' at plugin execution level
> --
>
> Key: MBUILDCACHE-92
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-92
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Réda Housni Alaoui
>Priority: Major
>
> I have the following case:
> {code:xml}
>
> com.github.eirslett
> frontend-maven-plugin
>
>
> yarn-build-dev
>
> yarn
>
> prepare-package
>
> ${build-dev.skip}
> build:dev
>
>
>
> yarn-build-prod
>
> yarn
>
> prepare-package
>
> ${build-prod.skip}
> build:prod
>
>
>
>
> {code}
> {{yarn-build-prod}} produce a more complete than {{yarn-build-dev}} but it
> also takes more time to execute:
> - on a dev environment (build-prod.skip=true and build-dev.skip=false) using
> a cache produced with build-prod.skip=false and build-dev.skip=true should
> lead to a cache hit
> - on a CI environment (build-prod.skip=false and build-dev.skip=true) using
> a cache produced with build-prod.skip=true and build-dev.skip=false should
> lead to a cache miss
> The only way I can think of implementing this is to track property {{skip}}
> only for execution id {{yarn-build-prod}}, but not for execution id
> {{yarn-build-dev}}.
> But I can't, because as of now, this extension allows to track plugin
> property with reconcile at plugin goal level, not execution level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-92) Allow to define 'reconciles' at plugin execution level
[
https://issues.apache.org/jira/browse/MBUILDCACHE-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Réda Housni Alaoui updated MBUILDCACHE-92:
--
Description:
I have the following case:
{code:xml}
com.github.eirslett
frontend-maven-plugin
yarn-build-dev
yarn
prepare-package
${build-dev.skip}
build:dev
yarn-build-prod
yarn
prepare-package
${build-prod.skip}
build:prod
{code}
{{yarn-build-prod}} produce a more complete than {{yarn-build-dev}} but it also
takes more time to execute:
- on a dev environment (build-prod.skip=true and build-dev.skip=false) using a
cache produced with build-prod.skip=false and build-dev.skip=true should lead
to a cache hit
- on a CI environement (build-prod.skip=false and build-dev.skip=true) using a
cache produced with build-prod.skip=true and build-dev.skip=false should lead
to a cache miss
The only way I can think of implementing this is to track property {{skip}}
only for execution id {{yarn-build-prod}}, but not for execution id
{{yarn-build-dev}}.
But I can't, because as of now, this extension allows to track plugin property
with reconcile at plugin goal level, not execution level.
was:
I have the following case:
{code:xml}
com.github.eirslett
frontend-maven-plugin
yarn-build-dev
yarn
prepare-package
${build-dev.skip}
build:dev
yarn-build-prod
yarn
prepare-package
${build-prod.skip}
build:prod
{code}
{{yarn-build-prod}} is a more complete {{yarn-build-dev}} but it also takes
more time to execute:
- on a dev environment (build-prod.skip=true and build-dev.skip=false) using a
cache produced with build-prod.skip=false and build-dev.skip=true should lead
to a cache hit
- on a CI environement (build-prod.skip=false and build-dev.skip=true) using a
cache produced with build-prod.skip=true and build-dev.skip=false should lead
to a cache miss
The only way I can think of implementing this is to track property {{skip}}
only for execution id {{yarn-build-prod}}, but not for execution id
{{yarn-build-dev}}.
But I can't, because as of now, this extension allows to track plugin property
with reconcile at plugin goal level, not execution level.
> Allow to define 'reconciles' at plugin execution level
> --
>
> Key: MBUILDCACHE-92
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-92
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Réda Housni Alaoui
>Priority: Major
>
> I have the following case:
> {code:xml}
>
> com.github.eirslett
> frontend-maven-plugin
>
>
> yarn-build-dev
>
> yarn
>
> prepare-package
>
> ${build-dev.skip}
> build:dev
>
>
>
> yarn-build-prod
>
> yarn
>
> prepare-package
>
> ${build-prod.skip}
> build:prod
>
>
>
>
> {code}
> {{yarn-build-prod}} produce a more complete than {{yarn-build-dev}} but it
> also takes more time to execute:
> - on a dev environment (build-prod.skip=true and build-dev.skip=false) using
> a cache produced with build-prod.skip=false and build-dev.skip=true should
> lead to a cache hit
> - on a CI environement (build-prod.skip=false and build-dev.skip=true) using
> a cache produced with build-prod.skip=true and build-dev.skip=false should
> lead to a cache miss
> The only way I can think of implementing this is to track property {{skip}}
> only for execution id {{yarn-build-prod}}, but not for execution id
> {{yarn-build-dev}}.
> But I can't, because as of now, this extension allows to track plugin
> property with reconcile at plugin goal level, not execution level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-92) Allow to define 'reconciles' at plugin execution level
Réda Housni Alaoui created MBUILDCACHE-92:
-
Summary: Allow to define 'reconciles' at plugin execution level
Key: MBUILDCACHE-92
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-92
Project: Maven Build Cache Extension
Issue Type: Improvement
Affects Versions: 1.1.0
Reporter: Réda Housni Alaoui
I have the following case:
{code:xml}
com.github.eirslett
frontend-maven-plugin
yarn-build-dev
yarn
prepare-package
${build-dev.skip}
build:dev
yarn-build-prod
yarn
prepare-package
${build-prod.skip}
build:prod
{code}
{{yarn-build-prod}} is a more complete {{yarn-build-dev}} but it also takes
more time to execute:
- on a dev environment (build-prod.skip=true and build-dev.skip=false) using a
cache produced with build-prod.skip=false and build-dev.skip=true should lead
to a cache hit
- on a CI environement (build-prod.skip=false and build-dev.skip=true) using a
cache produced with build-prod.skip=true and build-dev.skip=false should lead
to a cache miss
The only way I can think of implementing this is to track property {{skip}}
only for execution id {{yarn-build-prod}}, but not for execution id
{{yarn-build-dev}}.
But I can't, because as of now, this extension allows to track plugin property
with reconcile at plugin goal level, not execution level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [I] Split mvnd for Maven 3.x and 4.x support [maven-mvnd]
cstamas commented on issue #973: URL: https://github.com/apache/maven-mvnd/issues/973#issuecomment-2077665944 None. Go for it -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Upgrade to Maven 4.0.0-beta-1 [maven-mvnd]
gnodet opened a new pull request, #974: URL: https://github.com/apache/maven-mvnd/pull/974 - **Switch back to support only Maven 4.0.x** - **Switch version to 2.0-SNAPSHOT** - **Upgrade to beta 1** -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [ARCHETYPE-637] fix PomUtils.addNewModule Pretty-Printing issue on java 9+ [maven-archetype]
ascopes commented on PR #128: URL: https://github.com/apache/maven-archetype/pull/128#issuecomment-2077469466 Is there any chance of this being released in the near future? It has been sitting on master for almost a year now by the looks. -- 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] (ARCHETYPE-637) PomUtils.addNewModule Pretty-Printing has issue on java 9+
[ https://issues.apache.org/jira/browse/ARCHETYPE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840842#comment-17840842 ] ASF GitHub Bot commented on ARCHETYPE-637: -- ascopes commented on PR #128: URL: https://github.com/apache/maven-archetype/pull/128#issuecomment-2077469466 Is there any chance of this being released in the near future? It has been sitting on master for almost a year now by the looks. > PomUtils.addNewModule Pretty-Printing has issue on java 9+ > -- > > Key: ARCHETYPE-637 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-637 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Reporter: qxo >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 3.3.0 > > > > *As of Java 9, the _Transformer_ class's pretty-print feature doesn't define > the actual format. Therefore, whitespace-only nodes will be outputted as > well.* This has been discussed in this [JDK bug > ticket|https://bugs.openjdk.java.net/browse/JDK-8262285?attachmentViewMode=list]. > Also, [Java 9's release > note|https://www.oracle.com/java/technologies/javase/9-notes.html] has > explained this in the xml/jaxp section. > *If we want our pretty-print method to always generate the same format under > various Java versions, we need to provide a stylesheet file.* > ref： > [https://bugs.openjdk.java.net/browse/JDK-8262285?attachmentViewMode=list] > > [https://www.baeldung.com/java-pretty-print-xml#pretty-printing-xml-with-the-transformer-class] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840840#comment-17840840
]
ASF GitHub Bot commented on MBUILDCACHE-87:
---
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
In general, detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise:
1. The current implementation has a minor flaw because the dependencies are
merged into a single map. If the same dependency is present in the project and
the plugin and accounted for just once, it potentially creates a collision when
either of them is removed (removing one dependency will not change the checksum)
2. For traceability, plugin dependencies should be distinguishable from the
project dependencies in the `buildInfo.xml`. Creating a separate,
self-explaining `DigestItem` for them is better.
The logic of inspecting plugins should be moved one level up to
`calculateChecksum` and better be like this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- create 'DigetsItem's with plugin info (for traceability - to understand
the source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is the better traceability of the final
checksum.
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MBUILDCACHE-87] - Checksum should consider plugin dependencies [maven-build-cache-extension]
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
In general, detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise:
1. The current implementation has a minor flaw because the dependencies are
merged into a single map. If the same dependency is present in the project and
the plugin and accounted for just once, it potentially creates a collision when
either of them is removed (removing one dependency will not change the checksum)
2. For traceability, plugin dependencies should be distinguishable from the
project dependencies in the `buildInfo.xml`. Creating a separate,
self-explaining `DigestItem` for them is better.
The logic of inspecting plugins should be moved one level up to
`calculateChecksum` and better be like this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- create 'DigetsItem's with plugin info (for traceability - to understand
the source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is the better traceability of the final
checksum.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [MBUILDCACHE-87] - Checksum should consider plugin dependencies [maven-build-cache-extension]
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
In general, detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise:
1. The current implementation has a small flaw because the dependencies are
merged into a single map. If the same dependency is present in the project and
the plugin and accounted for just once, it potentially creates a collision when
either of them is removed (removing one dependency will not change the checksum)
2. Plugin dependencies should be distinguishable from the project
dependencies in the `buildInfo.xml` for traceability. Creating a separate,
self-explaining `DigestItem` for them is better. The logic of inspecting
plugins should be moved one level up to `calculateChecksum` and better be like
this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- create `DigetsItem`s with plugin info (for traceability - to understand
the source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is the better traceability of the final
checksum.
--
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-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840837#comment-17840837
]
ASF GitHub Bot commented on MBUILDCACHE-87:
---
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
In general, detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise:
1. The current implementation has a small flaw because the dependencies are
merged into a single map. If the same dependency is present in the project and
the plugin and accounted for just once, it potentially creates a collision when
either of them is removed (removing one dependency will not change the checksum)
2. Plugin dependencies should be distinguishable from the project
dependencies in the `buildInfo.xml` for traceability. Creating a separate,
self-explaining `DigestItem` for them is better. The logic of inspecting
plugins should be moved one level up to `calculateChecksum` and better be like
this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- create `DigetsItem`s with plugin info (for traceability - to understand
the source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is the better traceability of the final
checksum.
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-548) Artifact path/file improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840836#comment-17840836
]
ASF GitHub Bot commented on MRESOLVER-548:
--
cstamas commented on code in PR #482:
URL: https://github.com/apache/maven-resolver/pull/482#discussion_r1579626015
##
maven-resolver-api/src/main/java/org/eclipse/aether/artifact/AbstractArtifact.java:
##
@@ -96,30 +96,40 @@ public Artifact setVersion(String version) {
return newInstance(version, getProperties(), getPath());
}
+@Deprecated
+@Override
+public Artifact setFile(File file) {
+File current = getFile();
+if (Objects.equals(current, file)) {
+return this;
+}
+return newInstance(getVersion(), getProperties(), file != null ?
file.toPath() : null);
+}
+
/**
* This method should (and in Resolver is) overridden, but is kept just to
preserve backward compatibility if
* this class is extended somewhere.
*/
+@Override
public Path getPath() {
File file = getFile();
return file != null ? file.toPath() : null;
}
-@Deprecated
-@Override
-public Artifact setFile(File file) {
-return setPath(file != null ? file.toPath() : null);
-}
-
+/**
+ * This method should (and in Resolver is) overridden, but is kept just to
preserve backward compatibility if
+ * this class is extended somewhere.
+ */
@Override
public Artifact setPath(Path path) {
Path current = getPath();
if (Objects.equals(current, path)) {
return this;
}
-return newInstance(getVersion(), getProperties(), path);
+return setFile(path != null ? path.toFile() : null);
Review Comment:
This exec path is used ONLY for "outsiders" (ie ProvisioArtifact), all the
resolver internal classes override this method. For things like proviso to not
break virtual FS will need to be rewritten, as all they know about is File only.
> Artifact path/file improvements
> ---
>
> Key: MRESOLVER-548
> URL: https://issues.apache.org/jira/browse/MRESOLVER-548
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-11
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-548] Artifact file/path improvements [maven-resolver]
cstamas commented on code in PR #482:
URL: https://github.com/apache/maven-resolver/pull/482#discussion_r1579626015
##
maven-resolver-api/src/main/java/org/eclipse/aether/artifact/AbstractArtifact.java:
##
@@ -96,30 +96,40 @@ public Artifact setVersion(String version) {
return newInstance(version, getProperties(), getPath());
}
+@Deprecated
+@Override
+public Artifact setFile(File file) {
+File current = getFile();
+if (Objects.equals(current, file)) {
+return this;
+}
+return newInstance(getVersion(), getProperties(), file != null ?
file.toPath() : null);
+}
+
/**
* This method should (and in Resolver is) overridden, but is kept just to
preserve backward compatibility if
* this class is extended somewhere.
*/
+@Override
public Path getPath() {
File file = getFile();
return file != null ? file.toPath() : null;
}
-@Deprecated
-@Override
-public Artifact setFile(File file) {
-return setPath(file != null ? file.toPath() : null);
-}
-
+/**
+ * This method should (and in Resolver is) overridden, but is kept just to
preserve backward compatibility if
+ * this class is extended somewhere.
+ */
@Override
public Artifact setPath(Path path) {
Path current = getPath();
if (Objects.equals(current, path)) {
return this;
}
-return newInstance(getVersion(), getProperties(), path);
+return setFile(path != null ? path.toFile() : null);
Review Comment:
This exec path is used ONLY for "outsiders" (ie ProvisioArtifact), all the
resolver internal classes override this method. For things like proviso to not
break virtual FS will need to be rewritten, as all they know about is File only.
--
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] (MRESOLVER-548) Artifact path/file improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840835#comment-17840835
]
ASF GitHub Bot commented on MRESOLVER-548:
--
gnodet commented on code in PR #482:
URL: https://github.com/apache/maven-resolver/pull/482#discussion_r1579622273
##
maven-resolver-api/src/main/java/org/eclipse/aether/artifact/AbstractArtifact.java:
##
@@ -96,30 +96,40 @@ public Artifact setVersion(String version) {
return newInstance(version, getProperties(), getPath());
}
+@Deprecated
+@Override
+public Artifact setFile(File file) {
+File current = getFile();
+if (Objects.equals(current, file)) {
+return this;
+}
+return newInstance(getVersion(), getProperties(), file != null ?
file.toPath() : null);
+}
+
/**
* This method should (and in Resolver is) overridden, but is kept just to
preserve backward compatibility if
* this class is extended somewhere.
*/
+@Override
public Path getPath() {
File file = getFile();
return file != null ? file.toPath() : null;
}
-@Deprecated
-@Override
-public Artifact setFile(File file) {
-return setPath(file != null ? file.toPath() : null);
-}
-
+/**
+ * This method should (and in Resolver is) overridden, but is kept just to
preserve backward compatibility if
+ * this class is extended somewhere.
+ */
@Override
public Artifact setPath(Path path) {
Path current = getPath();
if (Objects.equals(current, path)) {
return this;
}
-return newInstance(getVersion(), getProperties(), path);
+return setFile(path != null ? path.toFile() : null);
Review Comment:
That's wrong. It goes out the NIO api which means a virtual FileSystem
cannot be used anymore.
> Artifact path/file improvements
> ---
>
> Key: MRESOLVER-548
> URL: https://issues.apache.org/jira/browse/MRESOLVER-548
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-11
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-548] Artifact file/path improvements [maven-resolver]
gnodet commented on code in PR #482:
URL: https://github.com/apache/maven-resolver/pull/482#discussion_r1579622273
##
maven-resolver-api/src/main/java/org/eclipse/aether/artifact/AbstractArtifact.java:
##
@@ -96,30 +96,40 @@ public Artifact setVersion(String version) {
return newInstance(version, getProperties(), getPath());
}
+@Deprecated
+@Override
+public Artifact setFile(File file) {
+File current = getFile();
+if (Objects.equals(current, file)) {
+return this;
+}
+return newInstance(getVersion(), getProperties(), file != null ?
file.toPath() : null);
+}
+
/**
* This method should (and in Resolver is) overridden, but is kept just to
preserve backward compatibility if
* this class is extended somewhere.
*/
+@Override
public Path getPath() {
File file = getFile();
return file != null ? file.toPath() : null;
}
-@Deprecated
-@Override
-public Artifact setFile(File file) {
-return setPath(file != null ? file.toPath() : null);
-}
-
+/**
+ * This method should (and in Resolver is) overridden, but is kept just to
preserve backward compatibility if
+ * this class is extended somewhere.
+ */
@Override
public Artifact setPath(Path path) {
Path current = getPath();
if (Objects.equals(current, path)) {
return this;
}
-return newInstance(getVersion(), getProperties(), path);
+return setFile(path != null ? path.toFile() : null);
Review Comment:
That's wrong. It goes out the NIO api which means a virtual FileSystem
cannot be used anymore.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Make TerminalOutput.pathToMaven() more robust to avoid #929 [maven-mvnd]
ppalaga merged PR #930: URL: https://github.com/apache/maven-mvnd/pull/930 -- 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] (MRESOLVER-548) Artifact path/file improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840833#comment-17840833 ] ASF GitHub Bot commented on MRESOLVER-548: -- cstamas opened a new pull request, #482: URL: https://github.com/apache/maven-resolver/pull/482 As original went from File to NIO2 Path, there were some changes left that may disturb code written agains Resolver 1. --- https://issues.apache.org/jira/browse/MRESOLVER-548 > Artifact path/file improvements > --- > > Key: MRESOLVER-548 > URL: https://issues.apache.org/jira/browse/MRESOLVER-548 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-548) Artifact path/file improvements
Tamas Cservenak created MRESOLVER-548: - Summary: Artifact path/file improvements Key: MRESOLVER-548 URL: https://issues.apache.org/jira/browse/MRESOLVER-548 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840832#comment-17840832 ] ASF GitHub Bot commented on MRESOLVER-547: -- cstamas merged PR #481: URL: https://github.com/apache/maven-resolver/pull/481 > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-547] Just use setVersion [maven-resolver]
cstamas merged PR #481: URL: https://github.com/apache/maven-resolver/pull/481 -- 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-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840830#comment-17840830
]
ASF GitHub Bot commented on MBUILDCACHE-87:
---
AlexanderAshitkin commented on PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#issuecomment-2077344363
In addition to the test created, it will be nice to cover with tests more
cases:
* External snapshot dependency is also accounted for in the checksum.
* Dependencies present both as a project dependency and a plugin dependency
are counted twice (adding plunging dependency in addition to existing project
dependency changes the checksum)
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MBUILDCACHE-87] - Checksum should consider plugin dependencies [maven-build-cache-extension]
AlexanderAshitkin commented on PR #146: URL: https://github.com/apache/maven-build-cache-extension/pull/146#issuecomment-2077344363 In addition to the test created, it will be nice to cover with tests more cases: * External snapshot dependency is also accounted for in the checksum. * Dependencies present both as a project dependency and a plugin dependency are counted twice (adding plunging dependency in addition to existing project dependency changes the checksum) -- 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-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840827#comment-17840827
]
ASF GitHub Bot commented on MBUILDCACHE-87:
---
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
In general, detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise:
1. The current implementation has a small flaw because the dependencies are
merged into a single map. If the same dependency is present in the project and
the plugin and accounted for just once, it potentially creates a collision when
either of them is removed (removing one dependency will not change the checksum)
2. such dependencies should be distinguishable from the project dependencies
in the `buildInfo.xml` for traceability. Creating a separate, self-explaining
`DigestItem` for them is better. The logic of inspecting plugins should be
moved one level up to `calculateChecksum` and better be like this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- create `DigetsItem`s with plugin info (for traceability - to understand
the source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is the better traceability of the final
checksum.
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MBUILDCACHE-87] - Checksum should consider plugin dependencies [maven-build-cache-extension]
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
In general, detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise:
1. The current implementation has a small flaw because the dependencies are
merged into a single map. If the same dependency is present in the project and
the plugin and accounted for just once, it potentially creates a collision when
either of them is removed (removing one dependency will not change the checksum)
2. such dependencies should be distinguishable from the project dependencies
in the `buildInfo.xml` for traceability. Creating a separate, self-explaining
`DigestItem` for them is better. The logic of inspecting plugins should be
moved one level up to `calculateChecksum` and better be like this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- create `DigetsItem`s with plugin info (for traceability - to understand
the source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is the better traceability of the final
checksum.
--
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-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840823#comment-17840823
]
ASF GitHub Bot commented on MBUILDCACHE-87:
---
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
The logic of detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise, such dependencies should be distinguishable from the
project dependencies in the `buildInfo.xml` for traceability. Creating a
separate, self-explaining `DigestItem` for them is better. The logic of
inspecting plugins should be moved one level up to `calculateChecksum` and
better be like this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- filter out dependencies already counted as a project dependency
- create `DigetsItem`s with plugin info (for traceability - to understand
the source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is a better traceability of the final checksum.
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MBUILDCACHE-87] - Checksum should consider plugin dependencies [maven-build-cache-extension]
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
The logic of detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise, such dependencies should be distinguishable from the
project dependencies in the `buildInfo.xml` for traceability. Creating a
separate, self-explaining `DigestItem` for them is better. The logic of
inspecting plugins should be moved one level up to `calculateChecksum` and
better be like this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- filter out dependencies already counted as a project dependency
- create `DigetsItem`s with plugin info (for traceability - to understand
the source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is a better traceability of the final checksum.
--
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-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840820#comment-17840820
]
ASF GitHub Bot commented on MBUILDCACHE-87:
---
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
The logic of detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise, such dependencies should be distinguishable from the
project dependencies in the `buildInfo.xml` for traceability. Creating a
separate, self-explaining `DigestItem` for them is better. The logic of
inspecting plugins should be moved one level up to `calculateChecksum` and
better be like this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- filter out dependencies already counted as a project dependency
- create DigetsItem with plugin info (for traceability - to understand the
source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is a better traceability of the final checksum.
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MBUILDCACHE-87] - Checksum should consider plugin dependencies [maven-build-cache-extension]
AlexanderAshitkin commented on code in PR #146:
URL:
https://github.com/apache/maven-build-cache-extension/pull/146#discussion_r1579540296
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -617,7 +621,13 @@ private static boolean isReadable(Path entry) throws
IOException {
private SortedMap getMutableDependencies() throws
IOException {
SortedMap result = new TreeMap<>();
-for (Dependency dependency : project.getDependencies()) {
+Set dependencies = Stream.concat(
Review Comment:
The logic of detecting mutable dependencies in the build plugins looks
correct.
Implementation-wise, such dependencies should be distinguishable from the
project dependencies in the `buildInfo.xml` for traceability. Creating a
separate, self-explaining `DigestItem` for them is better. The logic of
inspecting plugins should be moved one level up to `calculateChecksum` and
better be like this:
```txt
For every plugin:
- find mutable plugin dependencies (slightly refactor
`getMutableDependencies` to accept dependencies list)
- filter out dependencies already counted as a project dependency
- create DigetsItem with plugin info (for traceability - to understand the
source of the particular component of the checksum)
- add the items to the overall checksum
- for all the above - add debug logs for troubleshooting
```
The benefit of this approach is a better traceability of the final checksum.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Use the new resolver provider [maven]
gnodet merged PR #1483: URL: https://github.com/apache/maven/pull/1483 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7601) Upgrade Apache Maven parent POM to version 38
[ https://issues.apache.org/jira/browse/MNG-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7601: - Issue Type: Dependency upgrade (was: New Feature) > Upgrade Apache Maven parent POM to version 38 > - > > Key: MNG-7601 > URL: https://issues.apache.org/jira/browse/MNG-7601 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-3, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Fix terminal usage in mvnd [maven]
gnodet merged PR #1486: URL: https://github.com/apache/maven/pull/1486 -- 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] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840793#comment-17840793 ] ASF GitHub Bot commented on MRESOLVER-547: -- cstamas opened a new pull request, #481: URL: https://github.com/apache/maven-resolver/pull/481 No need for full copy, Artifact is already immutable. Moreover, the instance may be not DefaultArtifact but something else. And finally, setVersion already have "optimization" to return this if version is same as the one we want to copy with. --- https://issues.apache.org/jira/browse/MRESOLVER-547 > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
Tamas Cservenak created MRESOLVER-547: - Summary: BF collector always copies artifacts, even when it should not Key: MRESOLVER-547 URL: https://issues.apache.org/jira/browse/MRESOLVER-547 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-11 Artifact instances are always copied, even when they should not be. https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2010] Parameterized Selection Does not Work [maven-surefire]
AlexShmydov commented on PR #476: URL: https://github.com/apache/maven-surefire/pull/476#issuecomment-2077093027 Hi all! Any news about this problem? -- 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] (SUREFIRE-2010) Parameterized Selection Does not Work
[
https://issues.apache.org/jira/browse/SUREFIRE-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840780#comment-17840780
]
ASF GitHub Bot commented on SUREFIRE-2010:
--
AlexShmydov commented on PR #476:
URL: https://github.com/apache/maven-surefire/pull/476#issuecomment-2077093027
Hi all! Any news about this problem?
> Parameterized Selection Does not Work
> -
>
> Key: SUREFIRE-2010
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2010
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, JUnit 5.x support
>Affects Versions: 3.0.0-M5
> Environment: Maven 3.6.3 and Ubuntu 20.04, but I suppose it happens
> everywhere
>Reporter: David Georg Reichelt
>Priority: Major
>
> In the current version (and also M6-SNAPSHOT), maven surefire is not capable
> of selecting parameterized tests based on the index. In
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html,]
> it is described that this should work by providing the index, e.g. using
> {code:java}
> -Dtest=MyTest#method[$INDEX]{code}
> or
> {code:java}
> -Dtest=MyTest#method[*]{code}
> for all.
>
> This happens both for JUnit 4 and JUnit 5.
> I created a mwe demonstrating this problem:
> [https://github.com/DaGeRe/parameterized-selection-demo]
> As far as I see it, the TestMethodFilter in
> [https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/TestMethodFilter.java#L45]
> does the filtering, but has only a descriptor in the form:
>
> {code:java}
> [engine:junit-jupiter]/[class:de.dagere.peass.ExampleTest]/[test-template:test(int)]{code}
>
> So there is not the concrete value, but only the information that an int
> should be provided. Therefore, I currently see not any option to fix this
> easily or get this running using a regex pattern.
> Do I oversee something, or is it planned to fix this? If not, it would be
> better to update the documentation site accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (MDEP-926) proxy settings ignored for dependencies
[ https://issues.apache.org/jira/browse/MDEP-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski moved MNG-8104 to MDEP-926: --- Component/s: (was: Core) Key: MDEP-926 (was: MNG-8104) Affects Version/s: (was: 3.9.6) Project: Maven Dependency Plugin (was: Maven) > proxy settings ignored for dependencies > --- > > Key: MDEP-926 > URL: https://issues.apache.org/jira/browse/MDEP-926 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Patrick Mackinlay >Priority: Major > Attachments: image-2024-04-23-12-02-38-218.png, settings.xml > > > The proxy settings are ignored for dependencies in maven 3.9.6 (working in > 3.9.2). > On a machine with no direct internet access, if you clear your local > repository with a command like: > rm -rf ~/.m2/repository/org/apache/maven/maven-core/2.2.1 > and then try and download the dependency: > mvn dependency:get -DgroupId=org.apache.maven -DartifactId=maven-core > -Dversion=2.2.1 > > It will fail. The proxy settings are ignored. However, it should be noted > that for plugins they are used, its only for dependencies that they are > ignored. > maven version 3.9.2 works, so looks like this was introduced in 3.9.3 > probably when the dependency plugin version was upgraded. > > I used a minimal settings.xml with just one proxy entry. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Maven 4.0.0-beta-1 updates [maven-resolver]
cstamas commented on PR #454: URL: https://github.com/apache/maven-resolver/pull/454#issuecomment-2076928072 Superseded by https://github.com/apache/maven-resolver/pull/480 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Maven 4.0.0-beta-1 updates [maven-resolver]
cstamas closed pull request #454: Maven 4.0.0-beta-1 updates URL: https://github.com/apache/maven-resolver/pull/454 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[ https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MWRAPPER-135: - Summary: Provide a reliable way to determine the Maven Wrapper type (was: Provide a reliable way to determine the Maven Wrapper version) > Provide a reliable way to determine the Maven Wrapper type > -- > > Key: MWRAPPER-135 > URL: https://issues.apache.org/jira/browse/MWRAPPER-135 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Plugin >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.3.2 > > > Just like MWRAPPER-134 but for type. I completely forgot about this. As this > way, tooling can figure out not only version but type (also for humans, just > peek at properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper version
Tamas Cservenak created MWRAPPER-135: Summary: Provide a reliable way to determine the Maven Wrapper version Key: MWRAPPER-135 URL: https://issues.apache.org/jira/browse/MWRAPPER-135 Project: Maven Wrapper Issue Type: Task Components: Maven Wrapper Plugin Reporter: Tamas Cservenak Fix For: 3.3.2 Just like MWRAPPER-134 but for type. I completely forgot about this. As this way, tooling can figure out not only version but type (also for humans, just peek at properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8100) Upgrade default plugin bindings
[
https://issues.apache.org/jira/browse/MNG-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8100:
-
Component/s: Plugins and Lifecycle
> Upgrade default plugin bindings
> ---
>
> Key: MNG-8100
> URL: https://issues.apache.org/jira/browse/MNG-8100
> Project: Maven
> Issue Type: Dependency upgrade
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.7
>
>
> {noformat}
> 3.9.x
> compiler3.11.0 -> 3.13.0
> surefire3.2.2 -> 3.2.5
> jar 3.3.0 -> 3.4.1
> plugin 3.9.0 -> 3.12.0
> 4.x
> compiler3.11.0 -> 3.13.0
> surefire3.1.2 -> 3.2.5
> jar 3.3.0 -> 3.4.1
> plugin 3.9.0 -> 3.12.0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8101) Upgrade Parent to 42
[ https://issues.apache.org/jira/browse/MNG-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8101: - Component/s: Bootstrap & Build > Upgrade Parent to 42 > > > Key: MNG-8101 > URL: https://issues.apache.org/jira/browse/MNG-8101 > Project: Maven > Issue Type: Dependency upgrade > Components: Bootstrap Build >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.9.7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8106) Maven Metadata corruption if repository directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8106.
Resolution: Fixed
> Maven Metadata corruption if repository directory role overlaps
> ---
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6,
> 4.0.0-alpha-2, 4.0.0-alpha-3, 4.0.0-alpha-4, 4.0.0-alpha-5, 4.0.0-alpha-7,
> 4.0.0-alpha-8, 4.0.0-alpha-9, 4.0.0-alpha-10, 4.0.0-alpha-12, 4.0.0-alpha-13
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role in repository is manifold (which IS against
> best practices), data loss occurs. Metadata will contain this or that, but
> not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of
> versions). Affected maven versions will simply drop "the other" metadata (so
> if last deployed using this directory as G, the A data will be missing, and
> other way around).
> Have to note that doing this kind of naming is against "best practices", but
> still, can occur, for example in case of some refactoring/renaming of long
> running project modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8106) Maven Metadata corruption if repository directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840740#comment-17840740
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas merged PR #1481:
URL: https://github.com/apache/maven/pull/1481
> Maven Metadata corruption if repository directory role overlaps
> ---
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6,
> 4.0.0-alpha-2, 4.0.0-alpha-3, 4.0.0-alpha-4, 4.0.0-alpha-5, 4.0.0-alpha-7,
> 4.0.0-alpha-8, 4.0.0-alpha-9, 4.0.0-alpha-10, 4.0.0-alpha-12, 4.0.0-alpha-13
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role in repository is manifold (which IS against
> best practices), data loss occurs. Metadata will contain this or that, but
> not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of
> versions). Affected maven versions will simply drop "the other" metadata (so
> if last deployed using this directory as G, the A data will be missing, and
> other way around).
> Have to note that doing this kind of naming is against "best practices", but
> still, can occur, for example in case of some refactoring/renaming of long
> running project modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8106) Maven Metadata corruption if repository directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840739#comment-17840739
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas merged PR #1480:
URL: https://github.com/apache/maven/pull/1480
> Maven Metadata corruption if repository directory role overlaps
> ---
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6,
> 4.0.0-alpha-2, 4.0.0-alpha-3, 4.0.0-alpha-4, 4.0.0-alpha-5, 4.0.0-alpha-7,
> 4.0.0-alpha-8, 4.0.0-alpha-9, 4.0.0-alpha-10, 4.0.0-alpha-12, 4.0.0-alpha-13
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role in repository is manifold (which IS against
> best practices), data loss occurs. Metadata will contain this or that, but
> not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of
> versions). Affected maven versions will simply drop "the other" metadata (so
> if last deployed using this directory as G, the A data will be missing, and
> other way around).
> Have to note that doing this kind of naming is against "best practices", but
> still, can occur, for example in case of some refactoring/renaming of long
> running project modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8106] Fix metadata merge [maven]
cstamas merged PR #1481: URL: https://github.com/apache/maven/pull/1481 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [3.9.x][MNG-8106] Fix metadata merge [maven]
cstamas merged PR #1480: URL: https://github.com/apache/maven/pull/1480 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MBUILDCACHE-91) maven-dependency-plugin:unpack reactor artifactItems have their versions expanded instead of being replaced by 'cache-extension-version'
[
https://issues.apache.org/jira/browse/MBUILDCACHE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Réda Housni Alaoui updated MBUILDCACHE-91:
--
Description:
I have a multi module project where module1 is used as a dependency of
{{maven-dependency-plugin:unpack}} declared in module2.
The plugin configuration in module2 pom.xml looks like this:
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
unpack-webstart-resources
unpack
generate-resources
${project.build.directory}/generated-resources/com/aqme/module1
${project.groupId}
module1
${project.version}
blob
{code}
The effective pom computed by version 1.1.0 of this extension contains
{{project.version}} of artifactItem#version expanded to its effective value
instead of {{cache-extension-version}}. This leads to cache miss when the only
difference is {{project.version}} effective value.
was:
I have a multi module project where module1 is used as a dependency of
{{maven-dependency-plugin:unpack}} declared in module2.
The plugin configuration in module2 pom.xml looks like this:
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
unpack-webstart-resources
unpack
generate-resources
${project.build.directory}/generated-resources/com/aqme/module1
${project.groupId}
module1
${project.version}
blob
{code}
The effective pom computed by version 1.1.0 of this extension contains
{{project.version}} expanded to its effective value instead of
{{cache-extension-version}}. This leads to cache miss when the only difference
is {{project.version}} effective value.
> maven-dependency-plugin:unpack reactor artifactItems have their versions
> expanded instead of being replaced by 'cache-extension-version'
> -
>
> Key: MBUILDCACHE-91
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-91
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
>
> I have a multi module project where module1 is used as a dependency of
> {{maven-dependency-plugin:unpack}} declared in module2.
> The plugin configuration in module2 pom.xml looks like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-webstart-resources
>
> unpack
>
> generate-resources
>
>
> ${project.build.directory}/generated-resources/com/aqme/module1
>
>
> ${project.groupId}
> module1
> ${project.version}
> blob
>
>
>
>
>
>
> {code}
> The effective pom computed by version 1.1.0 of this extension contains
> {{project.version}} of artifactItem#version expanded to its effective value
> instead of {{cache-extension-version}}. This leads to cache miss when the
> only difference is {{project.version}} effective value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-91) maven-dependency-plugin:unpack reactor artifactItems have their versions expanded instead of being replaced by 'cache-extension-version'
Réda Housni Alaoui created MBUILDCACHE-91:
-
Summary: maven-dependency-plugin:unpack reactor artifactItems have
their versions expanded instead of being replaced by 'cache-extension-version'
Key: MBUILDCACHE-91
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-91
Project: Maven Build Cache Extension
Issue Type: Improvement
Reporter: Réda Housni Alaoui
I have a multi module project where module1 is used as a dependency of
{{maven-dependency-plugin:unpack}} declared in module2.
The plugin configuration in module2 pom.xml looks like this:
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
unpack-webstart-resources
unpack
generate-resources
${project.build.directory}/generated-resources/com/aqme/module1
${project.groupId}
module1
${project.version}
blob
{code}
The effective pom computed by version 1.1.0 of this extension contains
{{project.version}} expanded to its effective value instead of
{{cache-extension-version}}. This leads to cache miss when the only difference
is {{project.version}} effective value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [3.9.x] [MNG-8106] IT [maven-integration-testing]
cstamas merged PR #337: URL: https://github.com/apache/maven-integration-testing/pull/337 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MNG-8106] IT [maven-integration-testing]
cstamas merged PR #336: URL: https://github.com/apache/maven-integration-testing/pull/336 -- 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
