[jira] [Commented] (MBUILDCACHE-21) Caching does not check permissions
[
https://issues.apache.org/jira/browse/MBUILDCACHE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537990#comment-17537990
]
Mark Dodgson commented on MBUILDCACHE-21:
-
Thanks for the information.
I was wondering if it should not error but perhaps show a warning (miss
configuration) and continue running without caching inaccessible locations
> Caching does not check permissions
> --
>
> Key: MBUILDCACHE-21
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-21
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Mark Dodgson
>Priority: Major
>
> Below is a minimal pom.xml file the illustrates the problem.
> Specifying a surefire systemPropertyVariable for `java.io.tmpdir` to the temp
> folder produces an `AccessDeniedException`
>
> *example pom.xml*
>
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> build_cache_test
> 1.0-SNAPSHOT
>
> 17
> 17
>
>
>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.0.0-SNAPSHOT
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
>
>
> true
> ${java.io.tmpdir}
>
>
>
>
>
> {code}
>
>
> *Output*
> {code:java}
> [INFO] Using XX hash algorithm for cache
> [INFO] Attempting to restore project from build cache
> [INFO] Going to calculate checksum for project [groupId=org.example,
> artifactId=build_cache_test]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.246 s
> [INFO] Finished at: 2022-05-17T06:13:08+01:00
> [INFO]
>
> [ERROR] Failed to calculate checksums for build_cache_test:
> java.nio.file.AccessDeniedException: /tmp/tracker-extract-3-files.111 {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7478) Improve transport selection for resolver
[ https://issues.apache.org/jira/browse/MNG-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537991#comment-17537991 ] Hudson commented on MNG-7478: - Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #32 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/32/ > Improve transport selection for resolver > > > Key: MNG-7478 > URL: https://issues.apache.org/jira/browse/MNG-7478 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > The NNG-7454 included resolver native transport and wagon transport for > resolver and retains Wagon as default transport. Also, change added setting > for the transport by user using user properties. Still, as the selection > logic relies on user properties, it makes it impossible to simply set "for > good" the selection, as it works only if set on command line. Moreover, the > default maven behavior is affected by this change (in case 3rd party > transport is installed), as in this case user MUST provide "auto" setting, > while before 3.9.0 this was NOT the case: transport just had to be installed > and proper transport was selected based on priorities. > Hence, following changes are proposed: > * Instead of user properties, core should use config properties (config + > system + user merged) instead, as this allows setting transport in places > like MAVEN_OPTS etc. > * Introduce "real" default setting (used when no user input regarding > transport) > The latter change needs a bit of explanation: currently, if no user input, > the code selects "wagon" as default value, and sets Wagon priority to MAX, > potentially inhibiting any other installed 3rd party transport. Hence, due > this change, users installing 3rd party transport now MUST provide transport > setting "auto", that is IMHO wrong (alters behavior unexpectedly, requires > user interaction where that was not the case before). > Hence, we need to introduce "default" case (no user input given), that ONLY > modifies Wagon priority in such way it ensures it "wins" over HttpTransport, > but DOES NOT inhibit any potentially installed 3rd party provider. The > "wagon" and "native" settings are unchanged (making sure that selected is > used and INHIBITS anything else), while "auto" mode differs from "default" > mode that it does not tamper with priorities at all (so stock maven with auto > mode would select native transport due their coded priorities). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7478) Improve transport selection for resolver
[ https://issues.apache.org/jira/browse/MNG-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537996#comment-17537996 ] Hudson commented on MNG-7478: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #46 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/46/ > Improve transport selection for resolver > > > Key: MNG-7478 > URL: https://issues.apache.org/jira/browse/MNG-7478 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > The NNG-7454 included resolver native transport and wagon transport for > resolver and retains Wagon as default transport. Also, change added setting > for the transport by user using user properties. Still, as the selection > logic relies on user properties, it makes it impossible to simply set "for > good" the selection, as it works only if set on command line. Moreover, the > default maven behavior is affected by this change (in case 3rd party > transport is installed), as in this case user MUST provide "auto" setting, > while before 3.9.0 this was NOT the case: transport just had to be installed > and proper transport was selected based on priorities. > Hence, following changes are proposed: > * Instead of user properties, core should use config properties (config + > system + user merged) instead, as this allows setting transport in places > like MAVEN_OPTS etc. > * Introduce "real" default setting (used when no user input regarding > transport) > The latter change needs a bit of explanation: currently, if no user input, > the code selects "wagon" as default value, and sets Wagon priority to MAX, > potentially inhibiting any other installed 3rd party transport. Hence, due > this change, users installing 3rd party transport now MUST provide transport > setting "auto", that is IMHO wrong (alters behavior unexpectedly, requires > user interaction where that was not the case before). > Hence, we need to introduce "default" case (no user input given), that ONLY > modifies Wagon priority in such way it ensures it "wins" over HttpTransport, > but DOES NOT inhibit any potentially installed 3rd party provider. The > "wagon" and "native" settings are unchanged (making sure that selected is > used and INHIBITS anything else), while "auto" mode differs from "default" > mode that it does not tamper with priorities at all (so stock maven with auto > mode would select native transport due their coded priorities). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MBUILDCACHE-21) Caching does not check permissions
[
https://issues.apache.org/jira/browse/MBUILDCACHE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537998#comment-17537998
]
Guillaume Nodet commented on MBUILDCACHE-21:
Yes, I agree we should avoid checking directories that are not accessible, in a
similar way that we already exclude by default hidden directories and files.
However, those directories seem very specific and I'm not sure we can check the
problem with permissions before actually listing the directory:
{code}
➜ mbuildcache-21 git:(MBUILDCACHE-20) ✗ ll
/var/folders/8c/60048nhx4sz7p2d9921fjd00gn/T/com.apple.avconferenced/
total 0
drwx--@ 2 gnodet staff64B Apr 28 08:47 TemporaryItems
➜ mbuildcache-21 git:(MBUILDCACHE-20) ✗ ll
/var/folders/8c/60048nhx4sz7p2d9921fjd00gn/T/com.apple.avconferenced/TemporaryItems
total 0
ls:
/var/folders/8c/60048nhx4sz7p2d9921fjd00gn/T/com.apple.avconferenced/TemporaryItems:
Operation not permitted
➜ mbuildcache-21 git:(MBUILDCACHE-20) ✗
{code}
I'll dig a bit more, but I'm not sure it would be a good idea to simply drop
{{IOException}} occurring during the check.
Another possibility would be to somehow change the _default_ config to exclude
the {{java.io.tmpdir}} folder.
> Caching does not check permissions
> --
>
> Key: MBUILDCACHE-21
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-21
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Mark Dodgson
>Priority: Major
>
> Below is a minimal pom.xml file the illustrates the problem.
> Specifying a surefire systemPropertyVariable for `java.io.tmpdir` to the temp
> folder produces an `AccessDeniedException`
>
> *example pom.xml*
>
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> build_cache_test
> 1.0-SNAPSHOT
>
> 17
> 17
>
>
>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.0.0-SNAPSHOT
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
>
>
> true
> ${java.io.tmpdir}
>
>
>
>
>
> {code}
>
>
> *Output*
> {code:java}
> [INFO] Using XX hash algorithm for cache
> [INFO] Attempting to restore project from build cache
> [INFO] Going to calculate checksum for project [groupId=org.example,
> artifactId=build_cache_test]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.246 s
> [INFO] Finished at: 2022-05-17T06:13:08+01:00
> [INFO]
>
> [ERROR] Failed to calculate checksums for build_cache_test:
> java.nio.file.AccessDeniedException: /tmp/tracker-extract-3-files.111 {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-build-cache-extension] gnodet merged pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
gnodet merged PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14 -- 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-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538007#comment-17538007 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- gnodet merged PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14 > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Priority: Major > Labels: pull-request-available > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (MBUILDCACHE-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved MBUILDCACHE-20. Fix Version/s: 1.0.0-alpha Assignee: Guillaume Nodet Resolution: Fixed > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538014#comment-17538014
]
Tamás Cservenák commented on MNG-7475:
--
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post thins module)
the build breaks for me. But the idea is there, and also this could "gradually"
be done for any other component not used as component (I hope), with maybe some
minor refactoring.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MBUILDCACHE-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538019#comment-17538019 ] Hudson commented on MBUILDCACHE-20: --- Build failed in Jenkins: Maven » Maven TLP » maven-build-cache-extension » master #19 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-build-cache-extension/job/master/19/ > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538014#comment-17538014
]
Tamás Cservenák edited comment on MNG-7475 at 5/17/22 7:59 AM:
---
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post this module) the
build breaks for me. But the idea is there, and also this could "gradually" be
done for any other component not used as component (I hope), with maybe some
minor refactoring.
was (Author: cstamas):
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post thins module)
the build breaks for me. But the idea is there, and also this could "gradually"
be done for any other component not used as component (I hope), with maybe some
minor refactoring.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(
[GitHub] [maven-build-cache-extension] gnodet opened a new pull request, #15: [MBUILDCACHE-21] Improve directory checks
gnodet opened a new pull request, #15: URL: https://github.com/apache/maven-build-cache-extension/pull/15 https://issues.apache.org/jira/browse/MBUILDCACHE-21 -- 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-21) Caching does not check permissions
[
https://issues.apache.org/jira/browse/MBUILDCACHE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538028#comment-17538028
]
ASF GitHub Bot commented on MBUILDCACHE-21:
---
gnodet opened a new pull request, #15:
URL: https://github.com/apache/maven-build-cache-extension/pull/15
https://issues.apache.org/jira/browse/MBUILDCACHE-21
> Caching does not check permissions
> --
>
> Key: MBUILDCACHE-21
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-21
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Mark Dodgson
>Priority: Major
>
> Below is a minimal pom.xml file the illustrates the problem.
> Specifying a surefire systemPropertyVariable for `java.io.tmpdir` to the temp
> folder produces an `AccessDeniedException`
>
> *example pom.xml*
>
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> build_cache_test
> 1.0-SNAPSHOT
>
> 17
> 17
>
>
>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.0.0-SNAPSHOT
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
>
>
> true
> ${java.io.tmpdir}
>
>
>
>
>
> {code}
>
>
> *Output*
> {code:java}
> [INFO] Using XX hash algorithm for cache
> [INFO] Attempting to restore project from build cache
> [INFO] Going to calculate checksum for project [groupId=org.example,
> artifactId=build_cache_test]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.246 s
> [INFO] Finished at: 2022-05-17T06:13:08+01:00
> [INFO]
>
> [ERROR] Failed to calculate checksums for build_cache_test:
> java.nio.file.AccessDeniedException: /tmp/tracker-extract-3-files.111 {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MBUILDCACHE-21) Caching does not check permissions
[
https://issues.apache.org/jira/browse/MBUILDCACHE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated MBUILDCACHE-21:
--
Labels: pull-request-available (was: )
> Caching does not check permissions
> --
>
> Key: MBUILDCACHE-21
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-21
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Mark Dodgson
>Priority: Major
> Labels: pull-request-available
>
> Below is a minimal pom.xml file the illustrates the problem.
> Specifying a surefire systemPropertyVariable for `java.io.tmpdir` to the temp
> folder produces an `AccessDeniedException`
>
> *example pom.xml*
>
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> build_cache_test
> 1.0-SNAPSHOT
>
> 17
> 17
>
>
>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.0.0-SNAPSHOT
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
>
>
> true
> ${java.io.tmpdir}
>
>
>
>
>
> {code}
>
>
> *Output*
> {code:java}
> [INFO] Using XX hash algorithm for cache
> [INFO] Attempting to restore project from build cache
> [INFO] Going to calculate checksum for project [groupId=org.example,
> artifactId=build_cache_test]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.246 s
> [INFO] Finished at: 2022-05-17T06:13:08+01:00
> [INFO]
>
> [ERROR] Failed to calculate checksums for build_cache_test:
> java.nio.file.AccessDeniedException: /tmp/tracker-extract-3-files.111 {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MBUILDCACHE-21) Caching does not check permissions
[
https://issues.apache.org/jira/browse/MBUILDCACHE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MBUILDCACHE-21:
---
Fix Version/s: 1.0.0-alpha
> Caching does not check permissions
> --
>
> Key: MBUILDCACHE-21
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-21
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Mark Dodgson
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0.0-alpha
>
>
> Below is a minimal pom.xml file the illustrates the problem.
> Specifying a surefire systemPropertyVariable for `java.io.tmpdir` to the temp
> folder produces an `AccessDeniedException`
>
> *example pom.xml*
>
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> build_cache_test
> 1.0-SNAPSHOT
>
> 17
> 17
>
>
>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.0.0-SNAPSHOT
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
>
>
> true
> ${java.io.tmpdir}
>
>
>
>
>
> {code}
>
>
> *Output*
> {code:java}
> [INFO] Using XX hash algorithm for cache
> [INFO] Attempting to restore project from build cache
> [INFO] Going to calculate checksum for project [groupId=org.example,
> artifactId=build_cache_test]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.246 s
> [INFO] Finished at: 2022-05-17T06:13:08+01:00
> [INFO]
>
> [ERROR] Failed to calculate checksums for build_cache_test:
> java.nio.file.AccessDeniedException: /tmp/tracker-extract-3-files.111 {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (MBUILDCACHE-21) Caching does not check permissions
[
https://issues.apache.org/jira/browse/MBUILDCACHE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MBUILDCACHE-21:
--
Assignee: Guillaume Nodet
> Caching does not check permissions
> --
>
> Key: MBUILDCACHE-21
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-21
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Mark Dodgson
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: pull-request-available
>
> Below is a minimal pom.xml file the illustrates the problem.
> Specifying a surefire systemPropertyVariable for `java.io.tmpdir` to the temp
> folder produces an `AccessDeniedException`
>
> *example pom.xml*
>
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> build_cache_test
> 1.0-SNAPSHOT
>
> 17
> 17
>
>
>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.0.0-SNAPSHOT
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M5
>
>
> true
> ${java.io.tmpdir}
>
>
>
>
>
> {code}
>
>
> *Output*
> {code:java}
> [INFO] Using XX hash algorithm for cache
> [INFO] Attempting to restore project from build cache
> [INFO] Going to calculate checksum for project [groupId=org.example,
> artifactId=build_cache_test]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.246 s
> [INFO] Finished at: 2022-05-17T06:13:08+01:00
> [INFO]
>
> [ERROR] Failed to calculate checksums for build_cache_test:
> java.nio.file.AccessDeniedException: /tmp/tracker-extract-3-files.111 {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538014#comment-17538014
]
Tamás Cservenák edited comment on MNG-7475 at 5/17/22 8:46 AM:
---
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post this module) the
build breaks for me. But the idea is there, and also this could "gradually" be
done for any other component not used as component (I hope), with maybe some
minor refactoring.
So, what we concluded:
* all releases of shrinkwrap resolver breaks with Maven 3.8.5
* to use it with ALL supported maven versions (incl 3.8.5) that PR above needs
to be ingested by shrinkwrap resolver
Now, does it happen in project, or in a fork, that remains to be answered.
was (Author: cstamas):
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post this module) the
build breaks for me. But the idea is there, and also this could "gradually" be
done for any other component not used as component (I hope), with maybe some
minor refactoring.
So, what we concluded:
* current release of shrinkwrap resolver breaks with Maven 3.8.5
* to use it with ALL supported maven versions (incl 3.8.5) that PR above needs
to be ingested by shrinkwrap resolver
Now, does it happen in project, or in a fork, that remains to be answered.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this resul
[jira] [Comment Edited] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538014#comment-17538014
]
Tamás Cservenák edited comment on MNG-7475 at 5/17/22 8:46 AM:
---
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post this module) the
build breaks for me. But the idea is there, and also this could "gradually" be
done for any other component not used as component (I hope), with maybe some
minor refactoring.
So, what we concluded:
* current release of shrinkwrap resolver breaks with Maven 3.8.5
* to use it with ALL supported maven versions (incl 3.8.5) that PR above needs
to be ingested by shrinkwrap resolver
Now, does it happen in project, or in a fork, that remains to be answered.
was (Author: cstamas):
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post this module) the
build breaks for me. But the idea is there, and also this could "gradually" be
done for any other component not used as component (I hope), with maybe some
minor refactoring.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/mo
[jira] [Comment Edited] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538014#comment-17538014
]
Tamás Cservenák edited comment on MNG-7475 at 5/17/22 8:52 AM:
---
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post this module) the
build breaks for me. But the idea is there, and also this could "gradually" be
done for any other component not used as component (I hope), with maybe some
minor refactoring.
So, what we concluded:
* all releases of shrinkwrap resolver breaks with Maven 3.8.5
* to use it with ALL supported maven versions (incl 3.8.5, 3.9.x...) that PR
above needs to be ingested by shrinkwrap resolver
Now, does it happen in project, or in a fork, that remains to be answered.
was (Author: cstamas):
[https://github.com/shrinkwrap/resolver/pull/166]
It "works for me" (at least the related Junit tests), so module and module
tests do pass, but I cannot build whole project as later (post this module) the
build breaks for me. But the idea is there, and also this could "gradually" be
done for any other component not used as component (I hope), with maybe some
minor refactoring.
So, what we concluded:
* all releases of shrinkwrap resolver breaks with Maven 3.8.5
* to use it with ALL supported maven versions (incl 3.8.5) that PR above needs
to be ingested by shrinkwrap resolver
Now, does it happen in project, or in a fork, that remains to be answered.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, thi
[jira] [Commented] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538040#comment-17538040
]
Tamás Cservenák commented on MNG-7475:
--
[~aloew] once you ping back, am also leaning to close this as "won't fix".
Would be nice to clean up issues for 3.8.6, as it is really closing, is behind
the corner soon.
In any case, if you need any more help, we can continue the discussion on Maven
Users ML.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538040#comment-17538040
]
Tamás Cservenák edited comment on MNG-7475 at 5/17/22 8:59 AM:
---
[~aloew] once you ping back, am also leaning to close this as "won't fix".
Would be nice to clean up issues for 3.8.6, as it is really closing, is behind
the corner soon.
In any case, if you need any more help, we can continue the discussion on Maven
Users ML https://maven.apache.org/mailing-lists.html
was (Author: cstamas):
[~aloew] once you ping back, am also leaning to close this as "won't fix".
Would be nice to clean up issues for 3.8.6, as it is really closing, is behind
the corner soon.
In any case, if you need any more help, we can continue the discussion on Maven
Users ML.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MSHARED-650) Fire ExecutionEvent from DefaultMavenReportExecutor
[
https://issues.apache.org/jira/browse/MSHARED-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538043#comment-17538043
]
Tamás Cservenák commented on MSHARED-650:
-
There is a related MNG-7479 as well, but I'd abstain from adding EventSpy to
plugin ream (export it to plugins, as related issue wants) for now (at
least until we sort out 3.8.6 and 3.9.0).
> Fire ExecutionEvent from DefaultMavenReportExecutor
> ---
>
> Key: MSHARED-650
> URL: https://issues.apache.org/jira/browse/MSHARED-650
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-reporting-exec
>Reporter: Matt Nelson
>Priority: Major
>
> The event spy features added currently only support plugin mojos. When
> building site all the report mojos are grouped together under the site plugin
> and do not enable the ability to profile the site and find slow mojos. I dug
> through the code and it appears that the {{DefaultMavenReportExecutor}}[1]
> could be instrumented with the Catapult to fire events for each report mojo
> that the {{EventSpy}}[2] can handle.
> [1]
> https://github.com/apache/maven-shared/blob/maven-reporting-exec-1.3/src/main/java/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.java
> [2]
> https://github.com/apache/maven/blob/maven-3.5.0/maven-core/src/main/java/org/apache/maven/eventspy/EventSpy.java
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MSHARED-1074) Improvement performance of getMavenVersion in ForkedLauncher
[
https://issues.apache.org/jira/browse/MSHARED-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538050#comment-17538050
]
Michael Osipov commented on MSHARED-1074:
-
The IT suite writes the Maven version to the console, this should be cached and
reused.
> Improvement performance of getMavenVersion in ForkedLauncher
>
>
> Key: MSHARED-1074
> URL: https://issues.apache.org/jira/browse/MSHARED-1074
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-verifier
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-verifier-next-release
>
>
> In method {{getMavenVersion}} in ForkedLauncher new Maven process is forked
> every time.
> We can cache output by Maven home or try to read from properties files in
> Maven home.
> There is also possibility to use Maven wrapper for executing - in this case
> we can read version form maven-wrapper.properties
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538051#comment-17538051
]
Andreas Loew commented on MNG-7475:
---
Sorry, [~cstamas] , here I am (have been stuck in meetings...) :)
Thanks a million - my customer definitely owes you a big virtual ice cream :P
for even proposing a PR for ShrinkWrap. Great work! :)
And yes, as the content of your PR looks very promising to me, I hereby give
*{color:#00875a}my "all-clear" that you may close this issue as "won't
fix"{color}* - and I'll concentrate on looking into forking ShrinkWrap and
applying your PR into my fork, and ty to move on from there...
*Thanks again to the whole Maven team for your kind help with this!* (y)
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-resolver] cstamas merged pull request #179: extract class PremanagedDependency
cstamas merged PR #179: URL: https://github.com/apache/maven-resolver/pull/179 -- 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-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538052#comment-17538052
]
Andreas Loew commented on MNG-7475:
---
.. and also thank you for the pointer to the Maven Users ML - I will definitely
use this in case I'll run into follow-up issues with my fork - even though I
think it should be simply possible to only selectively fork/"patch"
shrinkwrap-resolver-impl-maven and use the rest of the modules as-is.
Please be warned that once again, I will most likely only be able to try this
out over this coming weekend... :(
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] gnodet closed pull request #716: [MNG-7455] Another attempt to fix the concurrency issue
gnodet closed pull request #716: [MNG-7455] Another attempt to fix the concurrency issue URL: https://github.com/apache/maven/pull/716 -- 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-7455) [REGRESSION] IllegalStateException in SessionScope during guice injection in multithreaded build
[
https://issues.apache.org/jira/browse/MNG-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538055#comment-17538055
]
ASF GitHub Bot commented on MNG-7455:
-
gnodet closed pull request #716: [MNG-7455] Another attempt to fix the
concurrency issue
URL: https://github.com/apache/maven/pull/716
> [REGRESSION] IllegalStateException in SessionScope during guice injection in
> multithreaded build
>
>
> Key: MNG-7455
> URL: https://issues.apache.org/jira/browse/MNG-7455
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.5
>Reporter: Emond Papegaaij
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: pom.xml.effective
>
>
> Since Maven 3.8.5 we are seeing intermittent failures with the stacktrace
> below. With 3.8.4 we did not have this issue. Looking at the changelog I
> suspect this regression is caused by MNG-7347.
> {code:java}
> 09:36:53 [mvn-builder-keyhub-manual] [INFO] ---
> asciidoctor-maven-plugin:2.2.2:process-asciidoc (output-html-nl) @
> keyhub-manual ---
> 09:36:53 [mvn-builder-keyhub-manual] [WARNING] Error injecting:
> org.asciidoctor.maven.AsciidoctorMojo
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, java.lang.IllegalStateException
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for field at org.asciidoctor.maven.AsciidoctorMojo.session(Unknown Source)
> while locating org.asciidoctor.maven.AsciidoctorMojo
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException
> (InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
> at com.google.inject.internal.InjectorImpl.getInstance
> (InjectorImpl.java:1086)
> at org.eclipse.sisu.space.AbstractDeferredClass.get
> (AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision
> (ProviderInternalFactory.java:85)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision
> (InternalFactoryToInitializableAdapter.java:57)
> at com.google.inject.internal.ProviderInternalFactory$1.call
> (ProviderInternalFactory.java:66)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:112)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:127)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision
> (ProvisionListenerStackCallback.java:66)
> at com.google.inject.internal.ProviderInternalFactory.circularGet
> (ProviderInternalFactory.java:61)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get
> (InternalFactoryToInitializableAdapter.java:47)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
> at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue
> (LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:255)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:210)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:195)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.conc
[jira] [Commented] (MNG-7455) [REGRESSION] IllegalStateException in SessionScope during guice injection in multithreaded build
[
https://issues.apache.org/jira/browse/MNG-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538058#comment-17538058
]
ASF GitHub Bot commented on MNG-7455:
-
laeubi commented on PR #716:
URL: https://github.com/apache/maven/pull/716#issuecomment-1128630393
> is not really a problem as all derived sessions are cloned from the root
one, except for the value of the `MavenSession#getCurrentProject()` which
changes from one session to another.
I found especially this rather annoying, as one has to use the Legacy
Support to get the "current" session.
> [REGRESSION] IllegalStateException in SessionScope during guice injection in
> multithreaded build
>
>
> Key: MNG-7455
> URL: https://issues.apache.org/jira/browse/MNG-7455
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.5
>Reporter: Emond Papegaaij
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: pom.xml.effective
>
>
> Since Maven 3.8.5 we are seeing intermittent failures with the stacktrace
> below. With 3.8.4 we did not have this issue. Looking at the changelog I
> suspect this regression is caused by MNG-7347.
> {code:java}
> 09:36:53 [mvn-builder-keyhub-manual] [INFO] ---
> asciidoctor-maven-plugin:2.2.2:process-asciidoc (output-html-nl) @
> keyhub-manual ---
> 09:36:53 [mvn-builder-keyhub-manual] [WARNING] Error injecting:
> org.asciidoctor.maven.AsciidoctorMojo
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, java.lang.IllegalStateException
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for field at org.asciidoctor.maven.AsciidoctorMojo.session(Unknown Source)
> while locating org.asciidoctor.maven.AsciidoctorMojo
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException
> (InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
> at com.google.inject.internal.InjectorImpl.getInstance
> (InjectorImpl.java:1086)
> at org.eclipse.sisu.space.AbstractDeferredClass.get
> (AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision
> (ProviderInternalFactory.java:85)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision
> (InternalFactoryToInitializableAdapter.java:57)
> at com.google.inject.internal.ProviderInternalFactory$1.call
> (ProviderInternalFactory.java:66)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:112)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:127)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision
> (ProvisionListenerStackCallback.java:66)
> at com.google.inject.internal.ProviderInternalFactory.circularGet
> (ProviderInternalFactory.java:61)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get
> (InternalFactoryToInitializableAdapter.java:47)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
> at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue
> (LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:255)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBu
[jira] [Resolved] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák resolved MNG-7475.
--
Fix Version/s: (was: 3.8.6)
Resolution: Won't Fix
The fix materialized in form of a patch for the affected project, that
similarly like in MNG-7449 constructed Maven internal bits manually, instead to
rely on container as "factory" for components.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] cstamas closed pull request #738: [MNG-7475] Restore binary compat for FileProfileActivator
cstamas closed pull request #738: [MNG-7475] Restore binary compat for FileProfileActivator URL: https://github.com/apache/maven/pull/738 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas commented on pull request #738: [MNG-7475] Restore binary compat for FileProfileActivator
cstamas commented on PR #738: URL: https://github.com/apache/maven/pull/738#issuecomment-1128630134 Issue https://issues.apache.org/jira/browse/MNG-7475 got resolved differently: in this case Maven is used as dependency. -- 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-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538056#comment-17538056
]
ASF GitHub Bot commented on MNG-7475:
-
cstamas commented on PR #738:
URL: https://github.com/apache/maven/pull/738#issuecomment-1128630134
Issue https://issues.apache.org/jira/browse/MNG-7475 got resolved
differently: in this case Maven is used as dependency.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] laeubi commented on pull request #716: [MNG-7455] Another attempt to fix the concurrency issue
laeubi commented on PR #716: URL: https://github.com/apache/maven/pull/716#issuecomment-1128630393 > is not really a problem as all derived sessions are cloned from the root one, except for the value of the `MavenSession#getCurrentProject()` which changes from one session to another. I found especially this rather annoying, as one has to use the Legacy Support to get the "current" session. -- 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-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538057#comment-17538057
]
ASF GitHub Bot commented on MNG-7475:
-
cstamas closed pull request #738: [MNG-7475] Restore binary compat for
FileProfileActivator
URL: https://github.com/apache/maven/pull/738
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MNG-7475.
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7475) [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in FileProfileActivator.setPathTranslator()
[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538062#comment-17538062
]
Tamás Cservenák commented on MNG-7475:
--
Yes, I think as well, that only one module needs this patch, so forking whole
project is not needed. Still, be warned, that "best practice" for forks is to
clearly distinguish forks from the forked project (as later you will step on
that rake and will hit you in face). This means, {*}change the GAV of forked
project{*}. Simplest would be – and I hope you do use some repository manager
that is able to host Maven artifacts – to deploy complete shrinkwrap project on
alternate GAV, and then really just "flip" to patched JAR+POM of this single
changed module and use resolver from this alternate/patched GAV from that point
on.
Now, I have no idea how easy this would be, given the deep hierarchy of
arquillian POMs and heavy use of import scopes for POMs, so "overriding the
resolver GAV" may prove nightmare-ish... But let's discuss that once we are
there... :)
You are welcome, and the whole Maven team is happy to help, whenever it can ;)
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> -
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
>Reporter: Andreas Loew
>Assignee: Tamás Cservenák
>Priority: Major
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)..
[GitHub] [maven-resolver] caiwei-ebay commented on pull request #178: [MRESOLVER-7] download poms in parallel
caiwei-ebay commented on PR #178: URL: https://github.com/apache/maven-resolver/pull/178#issuecomment-1128643994 Separated the PR for PremanagedDependency refactoring and rebased the code. -- 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-7) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538064#comment-17538064 ] ASF GitHub Bot commented on MRESOLVER-7: caiwei-ebay commented on PR #178: URL: https://github.com/apache/maven-resolver/pull/178#issuecomment-1128643994 Separated the PR for PremanagedDependency refactoring and rebased the code. > Download dependency POMs in parallel > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Priority: Major > Attachments: resolver.log > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven] gnodet commented on pull request #716: [MNG-7455] Another attempt to fix the concurrency issue
gnodet commented on PR #716: URL: https://github.com/apache/maven/pull/716#issuecomment-1128656332 > > is not really a problem as all derived sessions are cloned from the root one, except for the value of the `MavenSession#getCurrentProject()` which changes from one session to another. > > I found especially this rather annoying, as one has to use the Legacy Support to get the "current" session. I think https://github.com/apache/maven/pull/743 should solve MNG-7455 too. -- 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-7455) [REGRESSION] IllegalStateException in SessionScope during guice injection in multithreaded build
[
https://issues.apache.org/jira/browse/MNG-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538070#comment-17538070
]
ASF GitHub Bot commented on MNG-7455:
-
gnodet commented on PR #716:
URL: https://github.com/apache/maven/pull/716#issuecomment-1128656332
> > is not really a problem as all derived sessions are cloned from the root
one, except for the value of the `MavenSession#getCurrentProject()` which
changes from one session to another.
>
> I found especially this rather annoying, as one has to use the Legacy
Support to get the "current" session.
I think https://github.com/apache/maven/pull/743 should solve MNG-7455 too.
> [REGRESSION] IllegalStateException in SessionScope during guice injection in
> multithreaded build
>
>
> Key: MNG-7455
> URL: https://issues.apache.org/jira/browse/MNG-7455
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.5
>Reporter: Emond Papegaaij
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.8.6
>
> Attachments: pom.xml.effective
>
>
> Since Maven 3.8.5 we are seeing intermittent failures with the stacktrace
> below. With 3.8.4 we did not have this issue. Looking at the changelog I
> suspect this regression is caused by MNG-7347.
> {code:java}
> 09:36:53 [mvn-builder-keyhub-manual] [INFO] ---
> asciidoctor-maven-plugin:2.2.2:process-asciidoc (output-html-nl) @
> keyhub-manual ---
> 09:36:53 [mvn-builder-keyhub-manual] [WARNING] Error injecting:
> org.asciidoctor.maven.AsciidoctorMojo
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, java.lang.IllegalStateException
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for field at org.asciidoctor.maven.AsciidoctorMojo.session(Unknown Source)
> while locating org.asciidoctor.maven.AsciidoctorMojo
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException
> (InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
> at com.google.inject.internal.InjectorImpl.getInstance
> (InjectorImpl.java:1086)
> at org.eclipse.sisu.space.AbstractDeferredClass.get
> (AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision
> (ProviderInternalFactory.java:85)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision
> (InternalFactoryToInitializableAdapter.java:57)
> at com.google.inject.internal.ProviderInternalFactory$1.call
> (ProviderInternalFactory.java:66)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:112)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision
> (ProvisionListenerStackCallback.java:127)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision
> (ProvisionListenerStackCallback.java:66)
> at com.google.inject.internal.ProviderInternalFactory.circularGet
> (ProviderInternalFactory.java:61)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get
> (InternalFactoryToInitializableAdapter.java:47)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
> at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue
> (LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup
> (DefaultPlexusContainer.java:255)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
> (DefaultMavenPluginManager.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:1
[jira] [Updated] (MDEP-757) bug with "non-test scoped test only dependencies found"
[
https://issues.apache.org/jira/browse/MDEP-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MDEP-757:
---
Description:
Starting with 3.2.0, I see this problem in one of my project modules:
{noformat}
[INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
foundation ---
[WARNING] Non-test scoped test only dependencies found:
[WARNING] com.fasterxml.jackson.core:jackson-databind:jar:2.12.2:compile
{noformat}
This is not correct:
{noformat}
% cd lib/foundation
% grep -r databind src/main
src/main/java/dev/data/DataSet.java:import
com.fasterxml.jackson.databind.annotation.JsonDeserialize;
src/main/java/dev/data/DataSet.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/WriteableLocator.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/ObjectMetadata.java:import
com.fasterxml.jackson.databind.annotation.JsonDeserialize;
src/main/java/dev/data/ObjectMetadata.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/DataDefinition.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/ObjectAttribute.java:import
com.fasterxml.jackson.databind.annotation.JsonDeserialize;
src/main/java/dev/data/ObjectAttribute.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/ObjectDefinition.java:import
com.fasterxml.jackson.databind.annotation.JsonDeserialize;
src/main/java/dev/data/ObjectDefinition.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/ImmutableDataObject.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
{noformat}
So this dependency is used all over the place in the main sources (which is why
it can not be in test scope). However, the plugin no longer (it did in 3.1.2)
recognize it (all the uses are just annotations, so I guess that is the
problem) and raises this error.
was:
Starting with 3.2.0, I see this problem in one of my project modules:
INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
foundation ---
[WARNING] Non-test scoped test only dependencies found:
[WARNING] com.fasterxml.jackson.core:jackson-databind:jar:2.12.2:compile
This is not correct:
% cd lib/foundation
% grep -r databind src/main
src/main/java/dev/data/DataSet.java:import
com.fasterxml.jackson.databind.annotation.JsonDeserialize;
src/main/java/dev/data/DataSet.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/WriteableLocator.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/ObjectMetadata.java:import
com.fasterxml.jackson.databind.annotation.JsonDeserialize;
src/main/java/dev/data/ObjectMetadata.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/DataDefinition.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/ObjectAttribute.java:import
com.fasterxml.jackson.databind.annotation.JsonDeserialize;
src/main/java/dev/data/ObjectAttribute.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/ObjectDefinition.java:import
com.fasterxml.jackson.databind.annotation.JsonDeserialize;
src/main/java/dev/data/ObjectDefinition.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
src/main/java/dev/data/ImmutableDataObject.java:import
com.fasterxml.jackson.databind.annotation.JsonSerialize;
So this dependency is used all over the place in the main sources (which is why
it can not be in test scope). However, the plugin no longer (it did in 3.1.2)
recognize it (all the uses are just annotations, so I guess that is the
problem) and raises this error.
> bug with "non-test scoped test only dependencies found"
> ---
>
> Key: MDEP-757
> URL: https://issues.apache.org/jira/browse/MDEP-757
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: mvn --version
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 11.0.11, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> Starting with 3.2.0, I see this problem in one of my project modules:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
> foundation ---
> [WARNING] Non-test scoped test only dependencies found:
> [WARNING] c
[jira] [Commented] (MWRAPPER-66) maven-wrapper.properties - incorrect header reported by rat plugin
[
https://issues.apache.org/jira/browse/MWRAPPER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538117#comment-17538117
]
Jorge Solórzano commented on MWRAPPER-66:
-
Actually this is valid (https://issues.apache.org/jira/browse/LEGAL-265), it's
not a license change, the issue is that RAT hasn't released the fix integrated
since 3 years ago:
https://github.com/apache/creadur-rat/pull/10
Anyway using the canonical URL just to avoid the RAT issue makes sense.
> maven-wrapper.properties - incorrect header reported by rat plugin
> ---
>
> Key: MWRAPPER-66
> URL: https://issues.apache.org/jira/browse/MWRAPPER-66
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Slawomir Jaranowski
>Priority: Critical
>
> In maven-wrapper.properties we have
> {code}
> # https://www.apache.org/licenses/LICENSE-2.0
> {code}
> instead
> {code}
> # http://www.apache.org/licenses/LICENSE-2.0
> {code}
> standard configuration of {{apache-rat-plugin}} used in Maven project report
> issues on it.
> reproduce - go to maven-parent project
> {code}
> mvn wrapper:wrapper
> mvn verify
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MWRAPPER-66) maven-wrapper.properties - incorrect header reported by rat plugin
[
https://issues.apache.org/jira/browse/MWRAPPER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538117#comment-17538117
]
Jorge Solórzano edited comment on MWRAPPER-66 at 5/17/22 11:18 AM:
---
Actually this is valid (https://issues.apache.org/jira/browse/LEGAL-265), it's
not a license change, the issue is that RAT hasn't released the fix integrated
since 3 years ago:
https://github.com/apache/creadur-rat/pull/10
Anyway using the canonical URL just to make RAT happy is ok.
was (Author: jorsol):
Actually this is valid (https://issues.apache.org/jira/browse/LEGAL-265), it's
not a license change, the issue is that RAT hasn't released the fix integrated
since 3 years ago:
https://github.com/apache/creadur-rat/pull/10
Anyway using the canonical URL just to avoid the RAT issue makes sense.
> maven-wrapper.properties - incorrect header reported by rat plugin
> ---
>
> Key: MWRAPPER-66
> URL: https://issues.apache.org/jira/browse/MWRAPPER-66
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Slawomir Jaranowski
>Priority: Critical
>
> In maven-wrapper.properties we have
> {code}
> # https://www.apache.org/licenses/LICENSE-2.0
> {code}
> instead
> {code}
> # http://www.apache.org/licenses/LICENSE-2.0
> {code}
> standard configuration of {{apache-rat-plugin}} used in Maven project report
> issues on it.
> reproduce - go to maven-parent project
> {code}
> mvn wrapper:wrapper
> mvn verify
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538133#comment-17538133
]
Tamás Cservenák commented on MNG-7468:
--
IMHO, it should _always warn only_ as you cannot tell what mojo does... for
example, it could get MojoExecution injected and tamper directly with it's own
config even...
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-wrapper] jorsol opened a new pull request, #42: [MWRAPPER-65] MavenWrapperDownloader.java ignores the MVNW_REPOURL env
jorsol opened a new pull request, #42: URL: https://github.com/apache/maven-wrapper/pull/42 This simplifies the MavenWrapperDownloader.java script by removing many of the redundant code that was already done on the shell script, fixing the problem when MVNW_REPOURL env variable was used but not read by the MavenWrapperDownloader.java. Also wrap the calls when MVNW_VERBOSE is used to a log function in the shell script. Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MWRAPPER) 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 `[MWRAPPER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MWRAPPER-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 integration tests successfully (`mvn -Prun-its clean verify`). 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). -- 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] (MWRAPPER-65) MavenWrapperDownloader.java ignores the MVNW_REPOURL env
[ https://issues.apache.org/jira/browse/MWRAPPER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538135#comment-17538135 ] ASF GitHub Bot commented on MWRAPPER-65: jorsol opened a new pull request, #42: URL: https://github.com/apache/maven-wrapper/pull/42 This simplifies the MavenWrapperDownloader.java script by removing many of the redundant code that was already done on the shell script, fixing the problem when MVNW_REPOURL env variable was used but not read by the MavenWrapperDownloader.java. Also wrap the calls when MVNW_VERBOSE is used to a log function in the shell script. Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MWRAPPER) 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 `[MWRAPPER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MWRAPPER-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 integration tests successfully (`mvn -Prun-its clean verify`). 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). > MavenWrapperDownloader.java ignores the MVNW_REPOURL env > > > Key: MWRAPPER-65 > URL: https://issues.apache.org/jira/browse/MWRAPPER-65 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0, 3.1.1 >Reporter: Jorge Solórzano >Priority: Normal > > Problem: > MavenWrapperDownloader.java does not read the environment variable > MVNW_REPOURL, so in the case the script has to fallback to the java download > version instead of wget/curl, then the behavior will be different and > actually might fail as the repository will not be the same. > Proposal: > Instead of making MavenWrapperDownloader.java more complex I actually propose > the opposite, the MavenWrapperDownloader.java can be simplified by removing > code that's already done by the script such as the reading of the property > file, the DEFAULT_DOWNLOAD_URL... basically make the > MavenWrapperDownloader.java to behave as curl and wget by passing > "$wrapperJarPath" "$wrapperUrl" parameters without a lot of the current logic > that's already done on the script. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538133#comment-17538133
]
Tamás Cservenák edited comment on MNG-7468 at 5/17/22 11:52 AM:
IMHO, it should _always warn only_ as you cannot tell what mojo does... for
example, it could get MojoExecution injected and tamper directly with it's own
config even... For sure not fail the build, as that would be a breaking and
unwanted change: Maven was always "forgiving" with misconstructed/wrong but
parseable XML configuration...
was (Author: cstamas):
IMHO, it should _always warn only_ as you cannot tell what mojo does... for
example, it could get MojoExecution injected and tamper directly with it's own
config even...
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] cstamas commented on pull request #741: [MNG-7468] Check unsupported plugins parameters in configuration
cstamas commented on PR #741: URL: https://github.com/apache/maven/pull/741#issuecomment-1128774345 -1 Maven should NEVER fail the build in this case... you simply don't know what Mojo does (it can inject MojoExecution and tamper directly with it's own config). -- 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-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538137#comment-17538137
]
ASF GitHub Bot commented on MNG-7468:
-
cstamas commented on PR #741:
URL: https://github.com/apache/maven/pull/741#issuecomment-1128774345
-1 Maven should NEVER fail the build in this case... you simply don't know
what Mojo does (it can inject MojoExecution and tamper directly with it's own
config).
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (MASSEMBLY-919) Transitive dependency of a test dependency is included
[
https://issues.apache.org/jira/browse/MASSEMBLY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MASSEMBLY-919.
-
Resolution: Incomplete
No response from issue creator for 2+ years, closing out.
> Transitive dependency of a test dependency is included
> --
>
> Key: MASSEMBLY-919
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-919
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
>Affects Versions: 3.1.0
>Reporter: Zsombor Gegesy
>Assignee: Mark Struberg
>Priority: Blocker
> Labels: patch-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have a simple module, with one compile 'module-a' dependency, and with one
> test dependency ('module-b'), which has a couple of 'compile' dependencies
> (module-b-1, module-b-2, etc)
> In my assembly.xml I have:
> {code:java}
>
>
> true
> tools
> false
>
> runtime
> true
>
>
> {code}
> I would assume, that in this case, only 'module-a.jar' ends in the tool
> folder, however, the plugin adds module-b-1, module-b-2, etc too - which is
> not expected, as they are dependencies of 'module-b', which has test scope
> only.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2085) Surefire fails build on Modules that don't use surefire at all if -DexcludedGroups is given
[
https://issues.apache.org/jira/browse/SUREFIRE-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Höller updated SUREFIRE-2085:
Description:
Assume a simple multi-module project with an API and an implementation module
with JUnit as the testing framework. The API module just has interfaces and no
unit tests at all, thus, no dependency to junit. It does not declare any
configuration of the surefire-plugin in its POM. The implementation module uses
junit 4.13.2 and has a few tests.
If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of the
API module with the following error message:
{quote}[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test) on
project sample-api: groups/excludedGroups require TestNG, JUnit48+ or JUnit 5
(a specific engine required on classpath) on project test classpath -> [Help 1]
{quote}
Note, that tests in the implementation module might (or might not) use
categories as explained [in the documentation|#Using_JUnit_Categories].
IMHO Surefire should not fail the build in this situation as it would otherwise
require one to either declare an unused dependency or configure surefire to be
skipped, even if it's not used at all.
See also [https://www.mail-archive.com/users@maven.apache.org/msg143919.html].
was:
Assume a simple multi-module project with an API and an implementation module
with JUnit as the testing framework. The API module just has interfaces and no
unit tests at all, thus, no dependency to junit. It does not declare any
configuration of the surefire-plugin in its POM. The implementation module uses
junit 4.13.2 and has a few tests.
If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of the
API module with the following error message:
{quote}[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test) on
project sample-api: groups/excludedGroups require TestNG, JUnit48+ or JUnit 5
(a specific engine required on classpath) on project test classpath -> [Help 1]
{quote}
Note, that tests in the implementation module might (or might not) use
categories as explained [in the documentation|#Using_JUnit_Categories]].
IMHO Surefire should not fail the build in this situation as it would otherwise
require one to either declare an unused dependency or configure surefire to be
skipped, even if it's not used at all.
See also [https://www.mail-archive.com/users@maven.apache.org/msg143919.html].
> Surefire fails build on Modules that don't use surefire at all if
> -DexcludedGroups is given
> ---
>
> Key: SUREFIRE-2085
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2085
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Martin Höller
>Priority: Major
>
> Assume a simple multi-module project with an API and an implementation module
> with JUnit as the testing framework. The API module just has interfaces and
> no unit tests at all, thus, no dependency to junit. It does not declare any
> configuration of the surefire-plugin in its POM. The implementation module
> uses junit 4.13.2 and has a few tests.
> If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of
> the API module with the following error message:
> {quote}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test)
> on project sample-api: groups/excludedGroups require TestNG, JUnit48+ or
> JUnit 5 (a specific engine required on classpath) on project test classpath
> -> [Help 1]
> {quote}
> Note, that tests in the implementation module might (or might not) use
> categories as explained [in the documentation|#Using_JUnit_Categories].
> IMHO Surefire should not fail the build in this situation as it would
> otherwise require one to either declare an unused dependency or configure
> surefire to be skipped, even if it's not used at all.
> See also [https://www.mail-archive.com/users@maven.apache.org/msg143919.html].
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2085) Surefire fails build on Modules that don't use surefire at all if -DexcludedGroups is given
[
https://issues.apache.org/jira/browse/SUREFIRE-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Höller updated SUREFIRE-2085:
Description:
Assume a simple multi-module project with an API and an implementation module
with JUnit as the testing framework. The API module just has interfaces and no
unit tests at all, thus, no dependency to junit. It does not declare any
configuration of the surefire-plugin in its POM. The implementation module uses
junit 4.13.2 and has a few tests.
If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of the
API module with the following error message:
{quote}[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test) on
project sample-api: groups/excludedGroups require TestNG, JUnit48+ or JUnit 5
(a specific engine required on classpath) on project test classpath -> [Help 1]
{quote}
Note, that tests in the implementation module might (or might not) use
categories as explained [in the documentation|#Using_JUnit_Categories]].
IMHO Surefire should not fail the build in this situation as it would otherwise
require one to either declare an unused dependency or configure surefire to be
skipped, even if it's not used at all.
See also [https://www.mail-archive.com/users@maven.apache.org/msg143919.html].
was:
Assume a simple multi-module project with an API and an implementation module
with JUnit as the testing framework. The API module just has interfaces and no
unit tests at all, thus, no dependency to junit. It does not declare any
configuration of the surefire-plugin in its POM. The implementation module uses
junit 4.13.2 and has a few tests.
If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of the
API module with the following error message:
{quote}[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test) on
project sample-api: groups/excludedGroups require TestNG, JUnit48+ or JUnit 5
(a specific engine required on classpath) on project test classpath -> [Help 1]
{quote}
Note, that tests in the implementation module might (or mighht not) use
categories as explained [in the
documentation|[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_JUnit_Categories].]
IMHO Surefire should not fail the build in this situation as it would otherwise
require one to either declare an unused dependency or configure surefire to be
skipped, even if it's not used at all.
See also
[https://www.mail-archive.com/users@maven.apache.org/msg143919.html|https://www.mail-archive.com/users@maven.apache.org/msg143919.html.]
> Surefire fails build on Modules that don't use surefire at all if
> -DexcludedGroups is given
> ---
>
> Key: SUREFIRE-2085
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2085
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Martin Höller
>Priority: Major
>
> Assume a simple multi-module project with an API and an implementation module
> with JUnit as the testing framework. The API module just has interfaces and
> no unit tests at all, thus, no dependency to junit. It does not declare any
> configuration of the surefire-plugin in its POM. The implementation module
> uses junit 4.13.2 and has a few tests.
> If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of
> the API module with the following error message:
> {quote}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test)
> on project sample-api: groups/excludedGroups require TestNG, JUnit48+ or
> JUnit 5 (a specific engine required on classpath) on project test classpath
> -> [Help 1]
> {quote}
> Note, that tests in the implementation module might (or might not) use
> categories as explained [in the documentation|#Using_JUnit_Categories]].
> IMHO Surefire should not fail the build in this situation as it would
> otherwise require one to either declare an unused dependency or configure
> surefire to be skipped, even if it's not used at all.
> See also [https://www.mail-archive.com/users@maven.apache.org/msg143919.html].
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2085) Surefire fails build on Modules that don't use surefire at all if -DexcludedGroups is given
[
https://issues.apache.org/jira/browse/SUREFIRE-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Höller updated SUREFIRE-2085:
Description:
Assume a simple multi-module project with an API and an implementation module
with JUnit as the testing framework. The API module just has interfaces and no
unit tests at all, thus, no dependency to junit. It does not declare any
configuration of the surefire-plugin in its POM. The implementation module uses
junit 4.13.2 and has a few tests.
If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of the
API module with the following error message:
{quote}[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test) on
project sample-api: groups/excludedGroups require TestNG, JUnit48+ or JUnit 5
(a specific engine required on classpath) on project test classpath -> [Help 1]
{quote}
Note, that tests in the implementation module might (or might not) use
categories as explained [in the
documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_JUnit_Categories].
IMHO Surefire should not fail the build in this situation as it would otherwise
require one to either declare an unused dependency or configure surefire to be
skipped, even if it's not used at all.
See also [https://www.mail-archive.com/users@maven.apache.org/msg143919.html].
was:
Assume a simple multi-module project with an API and an implementation module
with JUnit as the testing framework. The API module just has interfaces and no
unit tests at all, thus, no dependency to junit. It does not declare any
configuration of the surefire-plugin in its POM. The implementation module uses
junit 4.13.2 and has a few tests.
If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of the
API module with the following error message:
{quote}[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test) on
project sample-api: groups/excludedGroups require TestNG, JUnit48+ or JUnit 5
(a specific engine required on classpath) on project test classpath -> [Help 1]
{quote}
Note, that tests in the implementation module might (or might not) use
categories as explained [in the documentation|#Using_JUnit_Categories].
IMHO Surefire should not fail the build in this situation as it would otherwise
require one to either declare an unused dependency or configure surefire to be
skipped, even if it's not used at all.
See also [https://www.mail-archive.com/users@maven.apache.org/msg143919.html].
> Surefire fails build on Modules that don't use surefire at all if
> -DexcludedGroups is given
> ---
>
> Key: SUREFIRE-2085
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2085
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Martin Höller
>Priority: Major
>
> Assume a simple multi-module project with an API and an implementation module
> with JUnit as the testing framework. The API module just has interfaces and
> no unit tests at all, thus, no dependency to junit. It does not declare any
> configuration of the surefire-plugin in its POM. The implementation module
> uses junit 4.13.2 and has a few tests.
> If I run {{mvn test -DexcludedGroups=SlowTest}} Surefire fails the build of
> the API module with the following error message:
> {quote}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (default-test)
> on project sample-api: groups/excludedGroups require TestNG, JUnit48+ or
> JUnit 5 (a specific engine required on classpath) on project test classpath
> -> [Help 1]
> {quote}
> Note, that tests in the implementation module might (or might not) use
> categories as explained [in the
> documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_JUnit_Categories].
> IMHO Surefire should not fail the build in this situation as it would
> otherwise require one to either declare an unused dependency or configure
> surefire to be skipped, even if it's not used at all.
> See also [https://www.mail-archive.com/users@maven.apache.org/msg143919.html].
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] gnodet commented on pull request #736: [3.8.x] [MNG-7476] Display a warning when an aggregator mojo is lock other mojos executions
gnodet commented on PR #736: URL: https://github.com/apache/maven/pull/736#issuecomment-1128791257 > @gnodet Can the reproducer be turned into an IT? @michael-o https://github.com/apache/maven-integration-testing/pull/162 -- 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-7476) Display a warning when an aggregator mojo is locking other mojo executions
[ https://issues.apache.org/jira/browse/MNG-7476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538145#comment-17538145 ] ASF GitHub Bot commented on MNG-7476: - gnodet commented on PR #736: URL: https://github.com/apache/maven/pull/736#issuecomment-1128791257 > @gnodet Can the reproducer be turned into an IT? @michael-o https://github.com/apache/maven-integration-testing/pull/162 > Display a warning when an aggregator mojo is locking other mojo executions > -- > > Key: MNG-7476 > URL: https://issues.apache.org/jira/browse/MNG-7476 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.8.5 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[
https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538155#comment-17538155
]
Tamás Cservenák commented on MASSEMBLY-874:
---
Confirmed, in a moment you have {{}} element in assembly
descriptor, this is happening.
> maven-assembly plugin always downloads dependencies from net
>
>
> Key: MASSEMBLY-874
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-874
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
> Environment: Multi-Module build
>Reporter: Roland Schäuble
>Assignee: Enrico Olivelli
>Priority: Major
> Attachments: make.log,
> maven_assembly_repositories_after_and_before_change.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The maven-assembly-plugin always loads it own dependencies from the internet,
> although the required dependencies are available in the local m2 repositiory.
> The local repository is updated with the dependencies but during the next
> build, the files are downloaded from the internet again instead of getting
> them from the local repo.
> In the attached log, near the end, the unnecessary downloads begin with
> "Downloading from central:
> [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.";|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.]
> The files are definitely available in my local repository under
> ~/.m2/repository/com/...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MASSEMBLY-870) Regression: Repository downloads all dependencies remotely into _tmp folders
[
https://issues.apache.org/jira/browse/MASSEMBLY-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538156#comment-17538156
]
Tamás Cservenák commented on MASSEMBLY-870:
---
Confirmed, same as MASSEMBLY-874: due repository element, this error is
triggered.
> Regression: Repository downloads all dependencies remotely into _tmp folders
>
>
> Key: MASSEMBLY-870
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-870
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Tuomas Kiviaho
>Priority: Major
>
> Repository {{_tmp}} folders under {{achive-tmp}} are filled with dependency
> artifacts (.jar files and all) from pom which are not met by the filtering. I
> noticed this when shifting from 2.6 to 3.1.0 and it is quite critical because
> these dependencies do not come from local repo, but instead they are always
> downloaded remotely.
> I do have {{dependency:copy}} also before this plugin which doesn't do this
> so I bet it has something to do with how the Aether is setup in
> {{DefaultRepositoryAssembler}}. By removing the {{}} section
> the assembly stopped this.
> The end result is now that everything that I've got in my pom is being filled
> into {{runner/tmp/repo_tmp}}.
> {code}
>
> provided
> false
>
>
> org.mortbay.jetty.alpn:alpn-boot
>
> runner/tmp/repo
>
>
> {code}
> Once the assembly is complete the _tmp folder gets deleted and the end result
> contains just that one jar file.
> This is kind of a blocker, because I bet people have got used over the years
> to cleaning the target folder so that they can get a nice assembly each time
> a dependency is being upgraded despite the efforts of incremental builds. Due
> to the cleaning there will always be repeated remote downloads because local
> repository in settings is not utilized.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[
https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538159#comment-17538159
]
Tamás Cservenák commented on MASSEMBLY-874:
---
But as I see plugin documentation for repository element, it kinda tells
something strange: "{*}NOTE:{*} Currently, only artifacts from the central
repository are allowed."
[https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_repository]
> maven-assembly plugin always downloads dependencies from net
>
>
> Key: MASSEMBLY-874
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-874
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
> Environment: Multi-Module build
>Reporter: Roland Schäuble
>Assignee: Enrico Olivelli
>Priority: Major
> Attachments: make.log,
> maven_assembly_repositories_after_and_before_change.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The maven-assembly-plugin always loads it own dependencies from the internet,
> although the required dependencies are available in the local m2 repositiory.
> The local repository is updated with the dependencies but during the next
> build, the files are downloaded from the internet again instead of getting
> them from the local repo.
> In the attached log, near the end, the unnecessary downloads begin with
> "Downloading from central:
> [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.";|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.]
> The files are definitely available in my local repository under
> ~/.m2/repository/com/...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (MASSEMBLY-952) Add support for GZIP-ing an existing TAR file
[ https://issues.apache.org/jira/browse/MASSEMBLY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MASSEMBLY-952. - Resolution: Won't Fix This is out of scope: m-assembly-p creates tar.gz, yes, but is not a "generic archiver" that gzips existing tar files... > Add support for GZIP-ing an existing TAR file > - > > Key: MASSEMBLY-952 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-952 > Project: Maven Assembly Plugin > Issue Type: New Feature >Affects Versions: 3.3.0 >Reporter: Steven Paligo >Priority: Major > > The Maven Assembly Plugin allows the user to create a TAR file and GZIP it > (using the "tar.gz" format). However it doesn't support GZIP-ing an existing > TAR file. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
AlexanderAshitkin commented on PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#issuecomment-1128838217 > > > @maximilian-novikov @maximilian-novikov-db could you have a look at this one ? I don't really understand why the remote cache would have to be checked before the local one... > > > > > > that's the good question, probably that's the legacy logic, which doesn't make sense after @AlexanderAshitkin added 'proper' plugins input reconciliation > > > > > > i would just fix this, without introducing a new flag > > > > Ok, I'll simplify the PR then. Hi The idea was to use the same artifact across all the cache consumers. By looking in the remote first it's possible to avoid using locally built artifacts and cached binaries should become eventually consistent across all nodes, even if remote cache was overridden. I cannot recall other implications except that, but discrepancies theoretically possible if binaries compared directly(snapshots?). But definitely local first lookup will work in majority of cases -- 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-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538171#comment-17538171 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- AlexanderAshitkin commented on PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#issuecomment-1128838217 > > > @maximilian-novikov @maximilian-novikov-db could you have a look at this one ? I don't really understand why the remote cache would have to be checked before the local one... > > > > > > that's the good question, probably that's the legacy logic, which doesn't make sense after @AlexanderAshitkin added 'proper' plugins input reconciliation > > > > > > i would just fix this, without introducing a new flag > > > > Ok, I'll simplify the PR then. Hi The idea was to use the same artifact across all the cache consumers. By looking in the remote first it's possible to avoid using locally built artifacts and cached binaries should become eventually consistent across all nodes, even if remote cache was overridden. I cannot recall other implications except that, but discrepancies theoretically possible if binaries compared directly(snapshots?). But definitely local first lookup will work in majority of cases > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-jxr] dependabot[bot] opened a new pull request, #55: Bump maven-parent from 35 to 36
dependabot[bot] opened a new pull request, #55: URL: https://github.com/apache/maven-jxr/pull/55 Bumps [maven-parent](https://github.com/apache/maven-parent) from 35 to 36. Release notes Sourced from https://github.com/apache/maven-parent/releases";>maven-parent's releases. 36 What's Changed [MPOM-300] switch from GA to ASF Matomo. by https://github.com/bmarwell";>@bmarwell in https://github-redirect.dependabot.com/apache/maven-parent/pull/58";>apache/maven-parent#58 [MPOM-308] Upgrade Maven PMD Plugin from 3.15.0 to 3.16.0 by https://github.com/slawekjaranowski";>@slawekjaranowski in https://github-redirect.dependabot.com/apache/maven-parent/pull/59";>apache/maven-parent#59 Bump taglist-maven-plugin from 2.4 to 3.0.0 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/apache/maven-parent/pull/45";>apache/maven-parent#45 Bump maven-jxr-plugin from 3.1.1 to 3.2.0 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/apache/maven-parent/pull/60";>apache/maven-parent#60 [MPOM-313] execute checkstyle in early phase of the build by https://github.com/olamy";>@olamy in https://github-redirect.dependabot.com/apache/maven-parent/pull/55";>apache/maven-parent#55 [MPOM-314] Upgrade modello-maven-plugin from 1.11 to 2.0.0 by https://github.com/slawekjaranowski";>@slawekjaranowski in https://github-redirect.dependabot.com/apache/maven-parent/pull/61";>apache/maven-parent#61 Bump apache from 25 to 26 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/apache/maven-parent/pull/62";>apache/maven-parent#62 New Contributors https://github.com/bmarwell";>@bmarwell made their first contribution in https://github-redirect.dependabot.com/apache/maven-parent/pull/58";>apache/maven-parent#58 https://github.com/olamy";>@olamy made their first contribution in https://github-redirect.dependabot.com/apache/maven-parent/pull/55";>apache/maven-parent#55 Full Changelog: https://github.com/apache/maven-parent/compare/maven-parent-35...maven-parent-36";>https://github.com/apache/maven-parent/compare/maven-parent-35...maven-parent-36 Commits See full diff in https://github.com/apache/maven-parent/commits";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-948) NullPointerException When useTransitiveDependencies False
[
https://issues.apache.org/jira/browse/MASSEMBLY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538185#comment-17538185
]
Tamás Cservenák commented on MASSEMBLY-948:
---
Essentially the org.apache.maven.project.MavenProject#dependencyArtifacts is
null, but it cannot be null when project has resolved dependencies (even w/o
dep it would be empty set, not null). Please create a reproducer and explain
how you invoke it, as it seems m-assembly-p in your case is invoked BEFORE
project dependencies are resolved?
> NullPointerException When useTransitiveDependencies False
> -
>
> Key: MASSEMBLY-948
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-948
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: David Mollitor
>Priority: Major
> Attachments: tez_assembly.xml
>
>
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
> gnu
> false
> false
>
>
>
> package-tez
>
> tez-${project.version}
>
> src/main/assembly/tez-dist.xml
>
>
> dir
> tar.gz
>
>
> prepare-package
>
> single
>
>
>
> package-tez-minimal
>
> tez-${project.version}-minimal
>
>
> src/main/assembly/tez-dist-minimal.xml
>
>
> dir
> tar.gz
>
>
> prepare-package
>
> single
>
>
>
>
> {code}
> {code:none}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single
> (package-tez-minimal) on project tez-dist: Execution package-tez-minimal of
> goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single
> (package-tez-minimal) on project tez-dist: Execution package-tez-minimal of
> goal org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> package-tez-minimal of goal
> org.apache.maven.plugins:maven-assembly-plugin:3.2.0:single failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.inte
[jira] [Closed] (MASSEMBLY-943) NPE if dependencySet includes Dependency with "provided" scope
[
https://issues.apache.org/jira/browse/MASSEMBLY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MASSEMBLY-943.
-
Resolution: Cannot Reproduce
As OP reported, seems to work with 3.2.0+
> NPE if dependencySet includes Dependency with "provided" scope
> --
>
> Key: MASSEMBLY-943
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-943
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 3.1.0
> Environment: Windows 10
>Reporter: df
>Priority: Major
> Labels: NullPointerException
> Attachments: stacktrace.txt
>
>
> Having an assembly descriptor of:
> {code:java}
>
> false
> out/dir
>
> com.example:a-runtime-artifact
>
>
> ${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}
>
> {code}
> and in the pom.xml
>
> {code:java}
>
>
> com.example
> a-runtime-artifact
> provided or runtime
>
>
> {code}
> yields to:
> {code:java}
> Execution make-assembly of goal
> org.apache.maven.plugins:maven-assembly-plugin:3.1.0:single failed.:
> NullPointerException)
> {code}
> see appended file [^stacktrace.txt].
>
> I would expect a more meaningful error message at least or even better it
> would just work ;).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874814667 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: @gnodet @maximilian-novikov-db remote honestly this change brings regression. There are 2 local caches: 1) local cache of remote repository 2) cache of local builds Previously, if remote build was present in local cache it was always used - there was no lookup. Now local build used with priority which could lead to difficult to debug issues. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874814667 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: @gnodet @maximilian-novikov-db remote honestly this change brings regression. There are 2 local caches: 1) local cache of remote repository 2) cache of local builds Previously, if remote build was present in local cache it was always used - there was no lookup. Now local build used with priority which could lead to difficult to debug issues. And performance benefits are minimal -- 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-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538191#comment-17538191 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874814667 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: @gnodet @maximilian-novikov-db remote honestly this change brings regression. There are 2 local caches: 1) local cache of remote repository 2) cache of local builds Previously, if remote build was present in local cache it was always used - there was no lookup. Now local build used with priority which could lead to difficult to debug issues. And performance benefits are minimal > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MBUILDCACHE-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538188#comment-17538188 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874814667 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: @gnodet @maximilian-novikov-db remote honestly this change brings regression. There are 2 local caches: 1) local cache of remote repository 2) cache of local builds Previously, if remote build was present in local cache it was always used - there was no lookup. Now local build used with priority which could lead to difficult to debug issues. > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-build-cache-extension] gnodet commented on a diff in pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
gnodet commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874823004 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... -- 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-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538200#comment-17538200 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- gnodet commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874823004 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-wrapper] jorsol opened a new pull request, #43: [MWRAPPER-66] - maven-wrapper.properties - incorrect header reported by rat plugin
jorsol opened a new pull request, #43: URL: https://github.com/apache/maven-wrapper/pull/43 While using `https` is valid per https://issues.apache.org/jira/browse/LEGAL-265, this just make RAT plugin happy (since the fix isn't released yet). Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MWRAPPER) 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 `[MWRAPPER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MWRAPPER-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 integration tests successfully (`mvn -Prun-its clean verify`). 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). -- 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] (MWRAPPER-66) maven-wrapper.properties - incorrect header reported by rat plugin
[
https://issues.apache.org/jira/browse/MWRAPPER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538204#comment-17538204
]
ASF GitHub Bot commented on MWRAPPER-66:
jorsol opened a new pull request, #43:
URL: https://github.com/apache/maven-wrapper/pull/43
While using `https` is valid per
https://issues.apache.org/jira/browse/LEGAL-265, this just make RAT plugin
happy (since the fix isn't released yet).
Following this checklist to help us incorporate your
contribution quickly and easily:
- [X] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MWRAPPER) 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 `[MWRAPPER-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MWRAPPER-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 integration tests successfully (`mvn -Prun-its clean
verify`).
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).
> maven-wrapper.properties - incorrect header reported by rat plugin
> ---
>
> Key: MWRAPPER-66
> URL: https://issues.apache.org/jira/browse/MWRAPPER-66
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Slawomir Jaranowski
>Priority: Critical
>
> In maven-wrapper.properties we have
> {code}
> # https://www.apache.org/licenses/LICENSE-2.0
> {code}
> instead
> {code}
> # http://www.apache.org/licenses/LICENSE-2.0
> {code}
> standard configuration of {{apache-rat-plugin}} used in Maven project report
> issues on it.
> reproduce - go to maven-parent project
> {code}
> mvn wrapper:wrapper
> mvn verify
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-build-cache-extension] gnodet commented on a diff in pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
gnodet commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874823004 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. -- 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-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538212#comment-17538212 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- gnodet commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874823004 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven] gnodet commented on pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope
gnodet commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1128894857 Not sure why tests aren't running. I'll close this one and recreate a new PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538213#comment-17538213 ] ASF GitHub Bot commented on MNG-7401: - gnodet commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1128894857 Not sure why tests aren't running. I'll close this one and recreate a new PR. > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven] gnodet closed pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope
gnodet closed pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope URL: https://github.com/apache/maven/pull/743 -- 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] (MASSEMBLY-942) Make "single" goal m2e-friendly by using BuildContext
[ https://issues.apache.org/jira/browse/MASSEMBLY-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538214#comment-17538214 ] Tamás Cservenák commented on MASSEMBLY-942: --- This will be revisited once in future, but not now. Not only that is not trivial work, but I personally would not invest energy into adding some API that is not Apache, is abandoned and clearly dead (not updated for 12 years)... and seems phased out by other emerging projects like [Takari Incremental build|https://github.com/takari/io.takari.incrementalbuild/blob/master/DOCUMENTATION.md#migrating-existing-maven-plugins] is. Obviously Maven needs to do something about this, but jumping on 1st gen of "incremental" API is not gonna happen IMHO (especially as Takari one claims it has Eclipse IDE integration as well). Considering all these were written by one same person (Igor F), we may need also some cross-board consultations as well... as this is not a trivial task IMHO. > Make "single" goal m2e-friendly by using BuildContext > - > > Key: MASSEMBLY-942 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-942 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: maven-archiver >Reporter: Mickael Istria >Priority: Major > > When using the maven-assembly-plugin "single" goal in Eclipse m2e, it shows > the usual errors regarding unsupported goals. > For best results in m2e (and all consumers, and for non-CLI builds in > general), the maven-assembly-plugin should leverage BuildContext and declare > m2e capabilities, as described in > https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538216#comment-17538216 ] ASF GitHub Bot commented on MNG-7401: - gnodet opened a new pull request, #743: URL: https://github.com/apache/maven/pull/743 https://issues.apache.org/jira/browse/MNG-7401 https://issues.apache.org/jira/browse/MNG-7474 @laeubi this supersedes https://github.com/apache/maven/pull/666 > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538215#comment-17538215 ] ASF GitHub Bot commented on MNG-7401: - gnodet closed pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope URL: https://github.com/apache/maven/pull/743 > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven] gnodet commented on pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope
gnodet commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1128898423 > Not sure why tests aren't running. I'll close this one and recreate a new PR. Ah, closing and reopening did the trick. -- 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] [Comment Edited] (MASSEMBLY-942) Make "single" goal m2e-friendly by using BuildContext
[ https://issues.apache.org/jira/browse/MASSEMBLY-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538214#comment-17538214 ] Tamás Cservenák edited comment on MASSEMBLY-942 at 5/17/22 1:51 PM: This will be revisited once in future, but not now. Not only that is not trivial work, but I personally would not invest energy into adding some API that is not Apache, is abandoned and clearly dead (not updated for 12 years)... and seems phased out by other emerging projects like [Takari Incremental build|https://github.com/takari/io.takari.incrementalbuild/blob/master/DOCUMENTATION.md#migrating-existing-maven-plugins] is. Obviously Maven needs to do something about this, but jumping on 1st gen of "incremental" API is not gonna happen IMHO (especially as Takari one claims it has Eclipse IDE integration as well and claims it supersedes the "first attempt", the BuildContext API). Also, considering all these were written by one same person (Igor F), we may need also some cross-board consultations as well... as this is not a trivial task IMHO. was (Author: cstamas): This will be revisited once in future, but not now. Not only that is not trivial work, but I personally would not invest energy into adding some API that is not Apache, is abandoned and clearly dead (not updated for 12 years)... and seems phased out by other emerging projects like [Takari Incremental build|https://github.com/takari/io.takari.incrementalbuild/blob/master/DOCUMENTATION.md#migrating-existing-maven-plugins] is. Obviously Maven needs to do something about this, but jumping on 1st gen of "incremental" API is not gonna happen IMHO (especially as Takari one claims it has Eclipse IDE integration as well). Considering all these were written by one same person (Igor F), we may need also some cross-board consultations as well... as this is not a trivial task IMHO. > Make "single" goal m2e-friendly by using BuildContext > - > > Key: MASSEMBLY-942 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-942 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: maven-archiver >Reporter: Mickael Istria >Priority: Major > > When using the maven-assembly-plugin "single" goal in Eclipse m2e, it shows > the usual errors regarding unsupported goals. > For best results in m2e (and all consumers, and for non-CLI builds in > general), the maven-assembly-plugin should leverage BuildContext and declare > m2e capabilities, as described in > https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538217#comment-17538217 ] ASF GitHub Bot commented on MNG-7401: - gnodet commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1128898423 > Not sure why tests aren't running. I'll close this one and recreate a new PR. Ah, closing and reopening did the trick. > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MASSEMBLY-942) Make "single" goal m2e-friendly by using BuildContext
[ https://issues.apache.org/jira/browse/MASSEMBLY-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538214#comment-17538214 ] Tamás Cservenák edited comment on MASSEMBLY-942 at 5/17/22 1:51 PM: This will be revisited once in future, but not now. Not only that is not trivial work, but I personally would not invest energy into adding some API that is not Apache, is abandoned and clearly dead (not updated for 12 years)... and seems phased out by other emerging projects like [Takari Incremental build|https://github.com/takari/io.takari.incrementalbuild/blob/master/DOCUMENTATION.md#migrating-existing-maven-plugins] is. Obviously Maven needs to do something about this, but jumping on 1st gen of "incremental" API is not gonna happen IMHO (especially as Takari one claims it has Eclipse IDE integration as well and claims it supersedes the "first attempt", the BuildContext API). Also, considering all these were written by one same person ([~igorf] ), we may need also some cross-board consultations as well... as this is not a trivial task IMHO. was (Author: cstamas): This will be revisited once in future, but not now. Not only that is not trivial work, but I personally would not invest energy into adding some API that is not Apache, is abandoned and clearly dead (not updated for 12 years)... and seems phased out by other emerging projects like [Takari Incremental build|https://github.com/takari/io.takari.incrementalbuild/blob/master/DOCUMENTATION.md#migrating-existing-maven-plugins] is. Obviously Maven needs to do something about this, but jumping on 1st gen of "incremental" API is not gonna happen IMHO (especially as Takari one claims it has Eclipse IDE integration as well and claims it supersedes the "first attempt", the BuildContext API). Also, considering all these were written by one same person (Igor F), we may need also some cross-board consultations as well... as this is not a trivial task IMHO. > Make "single" goal m2e-friendly by using BuildContext > - > > Key: MASSEMBLY-942 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-942 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: maven-archiver >Reporter: Mickael Istria >Priority: Major > > When using the maven-assembly-plugin "single" goal in Eclipse m2e, it shows > the usual errors regarding unsupported goals. > For best results in m2e (and all consumers, and for non-CLI builds in > general), the maven-assembly-plugin should leverage BuildContext and declare > m2e capabilities, as described in > https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538222#comment-17538222
]
ASF GitHub Bot commented on MNG-7468:
-
slawekjaranowski commented on PR #741:
URL: https://github.com/apache/maven/pull/741#issuecomment-1128908629
@cstamas
- can plugin descriptor simply have empty list of parameters?
- NEVER fail or don't check at all?
- or check in DefaultMojoExecutionConfigurator?
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] slawekjaranowski commented on pull request #741: [MNG-7468] Check unsupported plugins parameters in configuration
slawekjaranowski commented on PR #741: URL: https://github.com/apache/maven/pull/741#issuecomment-1128908629 @cstamas - can plugin descriptor simply have empty list of parameters? - NEVER fail or don't check at all? - or check in DefaultMojoExecutionConfigurator? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] laeubi closed pull request #666: MNG-7401 - Make MavenSession#getCurrentProject() using a thread local
laeubi closed pull request #666: MNG-7401 - Make MavenSession#getCurrentProject() using a thread local URL: https://github.com/apache/maven/pull/666 -- 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-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538223#comment-17538223 ] ASF GitHub Bot commented on MNG-7401: - laeubi closed pull request #666: MNG-7401 - Make MavenSession#getCurrentProject() using a thread local URL: https://github.com/apache/maven/pull/666 > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-mvnd] joschi commented on pull request #652: Add asdf install method
joschi commented on PR #652: URL: https://github.com/apache/maven-mvnd/pull/652#issuecomment-1128947754 > maybe move the [joschi/asdf-mvnd](https://github.com/joschi/asdf-mvnd) repo inside [@mvndaemon](https://github.com/mvndaemon) Happy to migrate the repository, but also happy to just keep it in my GitHub account. > * provide an update script so that releases can be update easily, @gnodet That's the beauty of asdf-vm: You don't need to update the plugin with every release. You only need to update it when your release/download location changed. 😄 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] joschi commented on a diff in pull request #652: Add asdf install method
joschi commented on code in PR #652: URL: https://github.com/apache/maven-mvnd/pull/652#discussion_r874894286 ## README.adoc: ## @@ -87,6 +87,15 @@ $ choco install mvndaemon $ scoop install mvndaemon +=== Install using https://github.com/joschi/asdf-mvnd#install[asdf] + +[source,shell] + +$ asdf plugin-add mvnd https://github.com/joschi/asdf-mvnd Review Comment: **suggestion:** Since the plugin is listed in the official asdf plugin directory at https://github.com/asdf-vm/asdf-plugins/, you don't need to add the Git repository. ```suggestion $ asdf plugin-add mvnd ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] joschi commented on pull request #652: Add asdf install method
joschi commented on PR #652: URL: https://github.com/apache/maven-mvnd/pull/652#issuecomment-1128951042 > update the scripts wrt to the new location of published binaries: [downloads.apache.org/maven/mvnd/0.8.0](https://downloads.apache.org/maven/mvnd/0.8.0/) @gnodet Any reason you're not updating the GitHub releases anymore (additionally to the Apache website)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet commented on pull request #652: Add asdf install method
gnodet commented on PR #652: URL: https://github.com/apache/maven-mvnd/pull/652#issuecomment-1128965910 > > update the scripts wrt to the new location of published binaries: [downloads.apache.org/maven/mvnd/0.8.0](https://downloads.apache.org/maven/mvnd/0.8.0/) > > @gnodet Any reason you're not updating the GitHub releases anymore (additionally to the Apache website)? Because this is the official channel for ASF releases: https://infra.apache.org/release-distribution -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet commented on pull request #652: Add asdf install method
gnodet commented on PR #652: URL: https://github.com/apache/maven-mvnd/pull/652#issuecomment-1128971884 > > maybe move the [joschi/asdf-mvnd](https://github.com/joschi/asdf-mvnd) repo inside [@mvndaemon](https://github.com/mvndaemon) > > Happy to migrate the repository, but also happy to just keep it in my GitHub account. If there's no need to update it with each release, I think we don't have to move the repo... > > * provide an update script so that releases can be update easily, > > @gnodet That's the beauty of asdf-vm: You don't need to update the plugin with every release. You only need to update it when your release/download location changed. 😄 Cool ! I missed that part... -- 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-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538253#comment-17538253 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874931070 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If #1 failed lookup remote repo and download 3) If #2 failed (effectively no remote build) - rebuild locally Now logic is: 1) Try to use local build even if build is present in remote repo 2) Try to find locally cached remote build 3) Loockup remote cache The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If \#1 failed lookup remote repo and download 3) If \#2 failed (effectively no remote build) - rebuild locally Now logic is: 1) Try to use local build even if build is present in remote repo 2) Try to find locally cached remote build 3) Loockup remote cache The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874931070 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If #1 failed lookup remote repo and download 3) If #2 failed (effectively no remote build) - rebuild locally Now logic is: 1) Try to use local build even if build is present in remote repo 2) Try to find locally cached remote build 3) Loockup remote cache The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If \#1 failed lookup remote repo and download 3) If \#2 failed (effectively no remote build) - rebuild locally Now logic is: 1) Try to use local build even if build is present in remote repo 2) Try to find locally cached remote build 3) Loockup remote cache The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874931070 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If 1 failed lookup remote repo and download 3) If 2 failed (effectively no remote build) - try use local build Now logic is: 1) Try to use local build even if build is present in remote repo 2) Try to find locally cached remote build 3) Loockup remote cache The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache -- 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-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538255#comment-17538255 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874931070 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If 1 failed lookup remote repo and download 3) If 2 failed (effectively no remote build) - try use local build Now logic is: 1) Try to use local build even if build is present in remote repo 2) Try to find locally cached remote build 3) Loockup remote cache The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874931070 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If 1 failed lookup remote repo and download 3) If 2 failed (effectively no remote build) - try use local build Now logic is: 1) Try to use local build even if reference build is present in remote repo 2) Try to find locally cached remote(reference) build 3) Lookup remote cache if 2 failed The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #14: [MBUILDCACHE-20] Use local cache before remote cache by default
AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874931070 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find a cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If 1 failed lookup remote repo and download 3) If 2 failed (effectively no remote build) - try use local build Now logic is: 1) Try to use local build even if reference build is present in remote repo 2) Try to find locally cached remote(reference) build 3) Lookup remote cache if 2 failed The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache -- 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-20) Allow configuring whether local or remote builds should be preferred
[ https://issues.apache.org/jira/browse/MBUILDCACHE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538259#comment-17538259 ] ASF GitHub Bot commented on MBUILDCACHE-20: --- AlexanderAshitkin commented on code in PR #14: URL: https://github.com/apache/maven-build-cache-extension/pull/14#discussion_r874931070 ## src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java: ## @@ -166,22 +166,22 @@ public CacheResult findCachedBuild( MavenSession session, MavenProject project, ProjectsInputInfo inputInfo = projectInputCalculator.calculateInput( project ); final CacheContext context = new CacheContext( project, inputInfo, session ); -// remote build first -CacheResult result = findCachedBuild( mojoExecutions, context ); Review Comment: > @AlexanderAshitkin Well, that was exactly what I was trying to fix. If there was no remote build cached, but a local build, a lookup did occur... This basically means that local builds are useless if you have a remote cache, because they are never used, which is a bit weird. Not exactly. This is lookup for a local build (which is not from remote cache) ``` // local build first CacheResult result = findLocalBuild( mojoExecutions, context ); ``` This is lookup to find cached build from remote repo (if missed - then lookup remote cache): ``` CacheResult remoteBuild = findCachedBuild( mojoExecutions, context ); ``` Old logic was: 1) Lookup local cache of remote repo 2) If 1 failed lookup remote repo and download 3) If 2 failed (effectively no remote build) - try use local build Now logic is: 1) Try to use local build even if reference build is present in remote repo 2) Try to find locally cached remote(reference) build 3) Lookup remote cache if 2 failed The new scheme has minimal performance benefits (both tried to find local build first), but likely will lead to less consistent results and difficult to debug discrepancies in presence of remote cache > Allow configuring whether local or remote builds should be preferred > > > Key: MBUILDCACHE-20 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-20 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: pull-request-available > Fix For: 1.0.0-alpha > > > Currently, a remote lookup is done first and if none succeeds, a lookup of a > previous local build is done (for a given input checksum). I don't really > understand the benefit of this and I think it should be reversed, or at least > made configurable. > The code is at: > https://github.com/apache/maven-build-cache-extension/blob/a3a44e72404228c536b5a8c21d2e67f0183452a1/src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java#L169-L187 -- This message was sent by Atlassian Jira (v8.20.7#820007)
