[jira] [Commented] (DOXIASITETOOLS-336) Make SiteRenderingContext#siteDirectories editable aware
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839939#comment-17839939
]
ASF GitHub Bot commented on DOXIASITETOOLS-336:
---
hboutemy commented on code in PR #150:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/150#discussion_r1575656039
##
doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/SiteRenderingContext.java:
##
@@ -271,7 +290,7 @@ public void addSiteDirectory(File siteDirectory) {
*
* @return List of site directories files.
*/
-public List getSiteDirectories() {
+public List getSiteDirectories() {
Review Comment:
yes, Doxia Sitetools is only used by Maven Site plugin: binary compatibility
is not really a topic, particularly when we are working on 2.0 milestones of
Doxia Sitetools
> Make SiteRenderingContext#siteDirectories editable aware
>
>
> Key: DOXIASITETOOLS-336
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-336
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 2.0.0-M16
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M18
>
>
> Right now you cannot qualify a {{siteDirectory}} whether the content is
> editable or generated. You need to perform multiple calls with distinct
> {{SiteRenderingContexts}}. This causes computational overhead is hacks like
> MSITE-723.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-336] Make SiteRenderingContext#siteDirectories editab… [maven-doxia-sitetools]
hboutemy commented on code in PR #150:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/150#discussion_r1575656039
##
doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/SiteRenderingContext.java:
##
@@ -271,7 +290,7 @@ public void addSiteDirectory(File siteDirectory) {
*
* @return List of site directories files.
*/
-public List getSiteDirectories() {
+public List getSiteDirectories() {
Review Comment:
yes, Doxia Sitetools is only used by Maven Site plugin: binary compatibility
is not really a topic, particularly when we are working on 2.0 milestones of
Doxia Sitetools
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[PR] Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.20.0 to 0.21.0 [maven-resolver]
dependabot[bot] opened a new pull request, #477: URL: https://github.com/apache/maven-resolver/pull/477 Bumps [com.github.siom79.japicmp:japicmp-maven-plugin](https://github.com/siom79/japicmp) from 0.20.0 to 0.21.0. Commits https://github.com/siom79/japicmp/commit/7dacdf1f429cad0f30238c3e1d12e728b5ddaa74;>7dacdf1 [maven-release-plugin] prepare release japicmp-base-0.21.0 https://github.com/siom79/japicmp/commit/98cc3f99d369f9145f25285a270a368ad42f1da9;>98cc3f9 upgraded version in *.md files to 0.21.0 https://github.com/siom79/japicmp/commit/dcd052ef5a5c01be8232bc8ee7a85bf2e4307d63;>dcd052e 0.21.0-SNAPSHOT https://github.com/siom79/japicmp/commit/2dbf22b5f4366089845f0e16de7c6692b6f7a2f0;>2dbf22b ReleaseNotes.md https://github.com/siom79/japicmp/commit/9c431387ccf82f07f2ba82e9cd252c3b23204b78;>9c43138 https://redirect.github.com/siom79/japicmp/issues/392;>#392 removed JpaAnalyzer.java https://github.com/siom79/japicmp/commit/97c4d6820bdd2d9c0ad9476fb9f897f839ba4e8d;>97c4d68 https://redirect.github.com/siom79/japicmp/issues/392;>#392 added new test case https://github.com/siom79/japicmp/commit/70e68e508b716d7459dfa230eabcc1a3e70c0cce;>70e68e5 https://redirect.github.com/siom79/japicmp/issues/392;>#392 added new JApiCompatibilityChangeType.ANNOTATION_MODIFIED https://github.com/siom79/japicmp/commit/1966906568ec7ceda5974b3bc20120b1f28b7708;>1966906 https://redirect.github.com/siom79/japicmp/issues/392;>#392 removed unnecessary blank lines https://github.com/siom79/japicmp/commit/6c09563ac5c0cd378840e8cacab51aa37ef242d8;>6c09563 https://redirect.github.com/siom79/japicmp/issues/392;>#392 correct output of annotation's value in HTML file https://github.com/siom79/japicmp/commit/1ede31d5354e6d57be20ceea3302642bfc56a1f0;>1ede31d https://redirect.github.com/siom79/japicmp/issues/392;>#392 merge changes from master Additional commits viewable in https://github.com/siom79/japicmp/compare/japicmp-base-0.20.0...japicmp-base-0.21.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.redisson:redisson from 3.28.0 to 3.29.0 [maven-resolver]
dependabot[bot] opened a new pull request, #476: URL: https://github.com/apache/maven-resolver/pull/476 Bumps [org.redisson:redisson](https://github.com/redisson/redisson) from 3.28.0 to 3.29.0. Release notes Sourced from https://github.com/redisson/redisson/releases;>org.redisson:redisson's releases. redisson-3.29.0 Feature - NewObjectListener added to track created objects Feature - NewObjectListener and SetObjectListener can be registered with RKeys.addListener() method Feature - subscribeOnElements(), subscribeOnLastElements() and subscribeOnFirstElements() methods wait for CompletionStage to complete before polling a next element Feature - shardedSubscriptionMode setting added in Cluster configuration Feature - RSemaphore.trySetPermits() method with ttl parameter added Feature - getDeletedIds() method added to RStream AutoClaimResult object Improvement - responses map lock replaced with fine-grained entry locking in RRemoteService and RScheduledExecutorService Fixed - RStream.autoClaim() method throws ClassCastException Fixed - RSearch aggregate expression applied incorrectly Fixed - LocalCachedMapDisabledKey event is parsed incorrectly if local cache used with RTransaction Fixed - Slave node in cluster mode isn't shutdown properly if readMode = MASTER and subscribeMode = MASTER (regression since 3.27.2) Fixed - race condition during cluster topology update causes slave added/removed events Fixed - OSGi MANIFEST should define optional dependencies Fixed - TimeoutException is thrown if connectionMinimumIdleSize = 0 Fixed - ClassCastException is thrown for Reactive/Rx RemoteService invocation if Redisson instance isn't Reactive/Rx Fixed - semaphore object is not deleted after RLocalCachedMap.clearLocalCache() method invocation Fixed - AggregationOptions.groupBy() setting with reducers used in RSearch.aggregate() method causes an exception Fixed - AggregationOptions.groupBy() setting usage with RSearch.aggregate() method causes an exception if reducers aren't defined Fixed - AggregationOptions.sortBy() setting usage with RSearch.aggregate() method causes an exception Fixed - resource leak error when executing multiple contains operation of RSet in transaction (thanks to https://github.com/wynn5a;>@wynn5a) Fixed - jmockit upgraded to 1.52.0 inside maven-surefire-plugin (thanks to https://github.com/roharon;>@roharon) Changelog Sourced from https://github.com/redisson/redisson/blob/master/CHANGELOG.md;>org.redisson:redisson's changelog. 22-Apr-2024 - 3.29.0 released Feature - NewObjectListener added to track created objects Feature - NewObjectListener and SetObjectListener can be registered with RKeys.addListener() method Feature - subscribeOnElements(), subscribeOnLastElements() and subscribeOnFirstElements() methods wait for CompletionStage to complete before polling the next element Feature - shardedSubscriptionMode setting added in Cluster configuration Feature - RSemaphore.trySetPermits() method with ttl parameter added Feature - getDeletedIds() method added to RStream AutoClaimResult object Improvement - responses map lock replaced with fine-grained entry locking in RRemoteService and RScheduledExecutorService Fixed - RStream.autoClaim() method throws ClassCastException Fixed - RSearch aggregate expression applied incorrectly Fixed - LocalCachedMapDisabledKey event is parsed incorrectly if local cache used with RTransaction Fixed - Slave node in cluster mode isn't shutdown properly if readMode = MASTER and subscribeMode = MASTER (regression since 3.27.2) Fixed - race condition during cluster topology update causes slave added/removed events Fixed - OSGi MANIFEST should define optional dependencies Fixed - TimeoutException is thrown if connectionMinimumIdleSize = 0 Fixed - ClassCastException is thrown for Reactive/Rx RemoteService invocation if Redisson instance isn't Reactive/Rx Fixed - semaphore object is not deleted after RLocalCachedMap.clearLocalCache() method invocation Fixed - AggregationOptions.groupBy() setting with reducers used in RSearch.aggregate() method causes an exception Fixed - AggregationOptions.groupBy() setting usage with RSearch.aggregate() method causes an exception if reducers aren't defined Fixed - AggregationOptions.sortBy() setting usage with RSearch.aggregate() method causes an exception Fixed - resource leak error when executing multiple contains operation of RSet in transaction (thanks to https://github.com/wynn5a;>@wynn5a) Fixed - jmockit upgraded to 1.52.0 inside maven-surefire-plugin (thanks to https://github.com/roharon;>@roharon) Commits https://github.com/redisson/redisson/commit/73a9e694b1e2422d0f4fff2d59796934c6c75920;>73a9e69 [maven-release-plugin] prepare release redisson-3.29.0
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839891#comment-17839891 ] ASF GitHub Bot commented on MCOMPILER-515: -- olamy commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071121026 > > I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. > > It is incomplete, but this is what the current plugin and the `javac` command line do. Implementing a better incremental build would probably be a multi-steps process. In medium term, my goal is to migrate the plugin from Maven 3 / Plexus API to Maven 4 / `javax.tools` API in order to improve JPMS support. Fixing some of the incremental build issues is a side effect of this work. The goal for now is only to preserve the existing functionalities (with bug fixes). > remove plexus-compiler layer but what about other compilers? > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
olamy commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071121026 > > I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. > > It is incomplete, but this is what the current plugin and the `javac` command line do. Implementing a better incremental build would probably be a multi-steps process. In medium term, my goal is to migrate the plugin from Maven 3 / Plexus API to Maven 4 / `javax.tools` API in order to improve JPMS support. Fixing some of the incremental build issues is a side effect of this work. The goal for now is only to preserve the existing functionalities (with bug fixes). > remove plexus-compiler layer but what about other compilers? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839889#comment-17839889 ] ASF GitHub Bot commented on MCOMPILER-515: -- hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071110405 I agree it is a lot of work. But you can't say this implementation will work either. It will be a bug farm. Inner classes, enums, and interface inheritance will all probably have weird and unexpected issues in more complex cases. And if there are classes compiled by other plugins like scalac? That's why bugs like this exist, because the mapping between java files and class files isn't clean. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071110405 I agree it is a lot of work. But you can't say this implementation will work either. It will be a bug farm. Inner classes, enums, and interface inheritance will all probably have weird and unexpected issues in more complex cases. And if there are classes compiled by other plugins like scalac? That's why bugs like this exist, because the mapping between java files and class files isn't clean. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
desruisseaux commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071095574 > I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. It is incomplete, but this is what the current plugin and the `javac` command line do. Implementing a better incremental build would probably be a multi-steps process. In medium term, my goal is to migrate the plugin from Maven 3 / Plexus API to Maven 4 / `javax.tools` API in order to improve JPMS support. Fixing some of the incremental build issues is a side effect of this work. The goal for now is only to preserve the existing functionalities (with bug fixes). After a refactored compiler plugin become stable enough, it would be possible to investigate how to do better. The proposal to use comma-separated values in `incrementalCompilation` parameters leaves room for that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839883#comment-17839883 ] ASF GitHub Bot commented on MCOMPILER-515: -- desruisseaux commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2071095574 > I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. It is incomplete, but this is what the current plugin and the `javac` command line do. Implementing a better incremental build would probably be a multi-steps process. In medium term, my goal is to migrate the plugin from Maven 3 / Plexus API to Maven 4 / `javax.tools` API in order to improve JPMS support. Fixing some of the incremental build issues is a side effect of this work. The goal for now is only to preserve the existing functionalities (with bug fixes). After a refactored compiler plugin become stable enough, it would be possible to investigate how to do better. The proposal to use comma-separated values in `incrementalCompilation` parameters leaves room for that. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-925) Require Maven 3.6.3
[ https://issues.apache.org/jira/browse/MDEP-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839868#comment-17839868 ] ASF GitHub Bot commented on MDEP-925: - slawekjaranowski opened a new pull request, #381: URL: https://github.com/apache/maven-dependency-plugin/pull/381 https://issues.apache.org/jira/browse/MDEP-925 > Require Maven 3.6.3 > --- > > Key: MDEP-925 > URL: https://issues.apache.org/jira/browse/MDEP-925 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-925) Require Maven 3.6.3
Slawomir Jaranowski created MDEP-925: Summary: Require Maven 3.6.3 Key: MDEP-925 URL: https://issues.apache.org/jira/browse/MDEP-925 Project: Maven Dependency Plugin Issue Type: Improvement Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.7.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839855#comment-17839855 ] ASF GitHub Bot commented on MCOMPILER-515: -- hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070978534 I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. You must know which .class files are generated from which .java files and in addition know which .class files depend upon which other .class files. If this isn't possible, then it isn't possible to implement this feature in a maintainable way. So either we need to track this additional information, or relax the requirement to so, module level or package level and track dependencies at that level. I am OK with either path but we shouldn't go ahead with only tracking file timestamps and acting like that is a working incremental build feature. On Monday, April 22, 2024 at 02:17:06 PM PDT, Martin Desruisseaux ***@***.***> wrote: While incremental builds is important, my reading of the source code inherited from Maven 3 suggests that in its current state, incremental build has bugs causing the opposite effect than what the plugin wanted to achieve. We could try to fix the Maven 3 compiler plugin, but I do not know if it is worth the effort given that the plugin is getting a significant rewrite for Maven 4. The current useIncrementalCompilation parameter is a boolean flag which is actually mixing at least two aspects: whether to check if a dependency changed, and how to detect which source files changed. I suggest to deprecate that parameter and replace it with a new incrementalCompilation parameter (same name but without use prefix). The value of that parameter would be a comma-separated list of the following: - dependencies: check whether a dependency changed. - sources: check whether a source file has been updated, or whether source files were added or removed. - classes: check whether a source file is more recent than its .class file. - modules (new): don't try to do incremental build in Maven, but delegate that task to javac instead. This is possible only with modular projects. It uses the --module compiler option, which is an alternative to enumerating all source files on the command-line. Equivalences with the current parameter: - useIncrementalCompilation = true is equivalent to incrementalCompilation = dependencies,sources (except maybe for the cases of newly added source files). - useIncrementalCompilation = false is equivalent to incrementalCompilation = classes. For an initial version of the Maven 4 compiler plugin, detection of changes would be based only on file timestamps. This is the same strategy than the current plugin. This approach would be unable to detect that a class needs to be recompiled because it depends on another class which has been changed. However, the current plugin cannot detect such cases neither, so we don't lost anything. If we support that feature in the future, it would be one new value in the above-cited list of comma-separated values. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839856#comment-17839856 ] ASF GitHub Bot commented on MBUILDCACHE-86: --- kbuntrock commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2070979208 The code introduced with MBUILDCACHE-80 has partially the same purpose of this MR. I need to adapt my code. First version of the merge can be seen in commit : https://github.com/apache/maven-build-cache-extension/pull/104/commits/c2878e17514ac909343e0ff10898b3bcbab0c2a7 But I still have some work since restored `target` directory shows some "weird" pom files.  > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Priority: Major > Labels: pull-request-available > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MBUILDCACHE-86] bugfix / enhancements restoration of outputs on disk [maven-build-cache-extension]
kbuntrock commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2070979208 The code introduced with MBUILDCACHE-80 has partially the same purpose of this MR. I need to adapt my code. First version of the merge can be seen in commit : https://github.com/apache/maven-build-cache-extension/pull/104/commits/c2878e17514ac909343e0ff10898b3bcbab0c2a7 But I still have some work since restored `target` directory shows some "weird" pom files.  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070978534 I can tell you with 100% certainty that only tracking file timestamps won't work and will be a bug farm. You must know which .class files are generated from which .java files and in addition know which .class files depend upon which other .class files. If this isn't possible, then it isn't possible to implement this feature in a maintainable way. So either we need to track this additional information, or relax the requirement to so, module level or package level and track dependencies at that level. I am OK with either path but we shouldn't go ahead with only tracking file timestamps and acting like that is a working incremental build feature. On Monday, April 22, 2024 at 02:17:06 PM PDT, Martin Desruisseaux ***@***.***> wrote: While incremental builds is important, my reading of the source code inherited from Maven 3 suggests that in its current state, incremental build has bugs causing the opposite effect than what the plugin wanted to achieve. We could try to fix the Maven 3 compiler plugin, but I do not know if it is worth the effort given that the plugin is getting a significant rewrite for Maven 4. The current useIncrementalCompilation parameter is a boolean flag which is actually mixing at least two aspects: whether to check if a dependency changed, and how to detect which source files changed. I suggest to deprecate that parameter and replace it with a new incrementalCompilation parameter (same name but without use prefix). The value of that parameter would be a comma-separated list of the following: - dependencies: check whether a dependency changed. - sources: check whether a source file has been updated, or whether source files were added or removed. - classes: check whether a source file is more recent than its .class file. - modules (new): don't try to do incremental build in Maven, but delegate that task to javac instead. This is possible only with modular projects. It uses the --module compiler option, which is an alternative to enumerating all source files on the command-line. Equivalences with the current parameter: - useIncrementalCompilation = true is equivalent to incrementalCompilation = dependencies,sources (except maybe for the cases of newly added source files). - useIncrementalCompilation = false is equivalent to incrementalCompilation = classes. For an initial version of the Maven 4 compiler plugin, detection of changes would be based only on file timestamps. This is the same strategy than the current plugin. This approach would be unable to detect that a class needs to be recompiled because it depends on another class which has been changed. However, the current plugin cannot detect such cases neither, so we don't lost anything. If we support that feature in the future, it would be one new value in the above-cited list of comma-separated values. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MDEP-924) Get rid of maven-artifact-transfer from list-classes goal
Slawomir Jaranowski created MDEP-924: Summary: Get rid of maven-artifact-transfer from list-classes goal Key: MDEP-924 URL: https://issues.apache.org/jira/browse/MDEP-924 Project: Maven Dependency Plugin Issue Type: Improvement Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.7.0 We can use Resolver API Done in simple Mojo as preparing for other. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-88) Tests in failure when ran on jdk21
[
https://issues.apache.org/jira/browse/MBUILDCACHE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated MBUILDCACHE-88:
--
Labels: pull-request-available (was: )
> Tests in failure when ran on jdk21
> --
>
> Key: MBUILDCACHE-88
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Kevin Buntrock
>Priority: Minor
> Labels: pull-request-available
>
> The project tests cannot be run on jdk21. Result is :
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
> but was:
> [ERROR]
> CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalEnabledByUserProperty:436->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalEnabledByUserProperty$51:439
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled:455->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled$54:457
> expected: but was:
> [INFO]
> [ERROR] Tests run: 71, Failures: 10, Errors: 0, Skipped: 4
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> {code}
> In class "CacheConfigImplTest", a method "deepMockConfigFile" mocks the
> result of the call to java.nio.file.Files.exists (via
> "FileSystemProvider.checkAccess").
> In jdk21 version, "Files.exists" does not rely on the same underlying
> "FileSystemProvider" method, therefore breaking the mocking purpose.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-88) Tests in failure when ran on jdk21
[
https://issues.apache.org/jira/browse/MBUILDCACHE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839854#comment-17839854
]
ASF GitHub Bot commented on MBUILDCACHE-88:
---
kbuntrock opened a new pull request, #147:
URL: https://github.com/apache/maven-build-cache-extension/pull/147
The project tests cannot be run on a jdk21. See :
https://issues.apache.org/jira/browse/MBUILDCACHE-88
Please not that this fix does not address the comment line 123 of
`CacheConfigImplTest.class` :
`// unfortunate and potentially fragile deep mocking, but helps avoid most
disk involvement while working around
// the static nio Files.exists method`
The mock implementation can still be considered as fragile.
--
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [MBUILDCACHE JIRA
issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Tests in failure when ran on jdk21
> --
>
> Key: MBUILDCACHE-88
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Kevin Buntrock
>Priority: Minor
>
> The project tests cannot be run on jdk21. Result is :
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
> but was:
> [ERROR]
> CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
> expected: but was:
> [ERROR]
>
[PR] [MBUILDCACHE-88] Fix tests execution on jdk > 20 [maven-build-cache-extension]
kbuntrock opened a new pull request, #147: URL: https://github.com/apache/maven-build-cache-extension/pull/147 The project tests cannot be run on a jdk21. See : https://issues.apache.org/jira/browse/MBUILDCACHE-88 Please not that this fix does not address the comment line 123 of `CacheConfigImplTest.class` : `// unfortunate and potentially fragile deep mocking, but helps avoid most disk involvement while working around // the static nio Files.exists method` The mock implementation can still be considered as fragile. -- Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [MBUILDCACHE JIRA issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839852#comment-17839852 ] ASF GitHub Bot commented on MCOMPILER-515: -- desruisseaux commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070967076 While incremental builds is important, my reading of the source code inherited from Maven 3 suggests that in its current state, incremental build has bugs causing the opposite effect than what the plugin wanted to achieve. We could try to fix the Maven 3 compiler plugin, but I do not know if it is worth the effort given that the plugin is getting a significant rewrite for Maven 4. The current `useIncrementalCompilation` parameter is a boolean flag which is actually mixing at least two aspects: whether to check if a dependency changed, and how to detect which source files changed. I suggest to deprecate that parameter and replace it with a new `incrementalCompilation` parameter (same name but without `use` prefix). The value of that parameter would be a comma-separated list of the following: * `dependencies`: check whether a dependency changed. * `sources`: check whether a source file has been updated, or whether source files were added or removed. * `classes`: check whether a source file is more recent than its `.class` file. * `modules` (new): don't try to do incremental build in Maven, but delegate that task to `javac` instead. This is possible only with modular projects. It uses the `--module` compiler option, which is an alternative to enumerating all source files on the command-line. Equivalences with the current parameter: * `useIncrementalCompilation = true` is equivalent to `incrementalCompilation = dependencies,sources` (except maybe for the cases of newly added source files). * `useIncrementalCompilation = false` is equivalent to `incrementalCompilation = classes`. For an initial version of the Maven 4 compiler plugin, detection of changes would be based only on file timestamps. This is the same strategy than the current plugin. This approach would be unable to detect that a class needs to be recompiled because it depends on another class which has been changed. However, the current plugin cannot detect such cases neither, so we don't lost anything. If we support that feature in the future, it would be one new value in the above-cited list of comma-separated values. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
desruisseaux commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070967076 While incremental builds is important, my reading of the source code inherited from Maven 3 suggests that in its current state, incremental build has bugs causing the opposite effect than what the plugin wanted to achieve. We could try to fix the Maven 3 compiler plugin, but I do not know if it is worth the effort given that the plugin is getting a significant rewrite for Maven 4. The current `useIncrementalCompilation` parameter is a boolean flag which is actually mixing at least two aspects: whether to check if a dependency changed, and how to detect which source files changed. I suggest to deprecate that parameter and replace it with a new `incrementalCompilation` parameter (same name but without `use` prefix). The value of that parameter would be a comma-separated list of the following: * `dependencies`: check whether a dependency changed. * `sources`: check whether a source file has been updated, or whether source files were added or removed. * `classes`: check whether a source file is more recent than its `.class` file. * `modules` (new): don't try to do incremental build in Maven, but delegate that task to `javac` instead. This is possible only with modular projects. It uses the `--module` compiler option, which is an alternative to enumerating all source files on the command-line. Equivalences with the current parameter: * `useIncrementalCompilation = true` is equivalent to `incrementalCompilation = dependencies,sources` (except maybe for the cases of newly added source files). * `useIncrementalCompilation = false` is equivalent to `incrementalCompilation = classes`. For an initial version of the Maven 4 compiler plugin, detection of changes would be based only on file timestamps. This is the same strategy than the current plugin. This approach would be unable to detect that a class needs to be recompiled because it depends on another class which has been changed. However, the current plugin cannot detect such cases neither, so we don't lost anything. If we support that feature in the future, it would be one new value in the above-cited list of comma-separated values. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MBUILDCACHE-88) Tests in failure when ran on jdk21
Kevin Buntrock created MBUILDCACHE-88:
-
Summary: Tests in failure when ran on jdk21
Key: MBUILDCACHE-88
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
Project: Maven Build Cache Extension
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Kevin Buntrock
The project tests cannot be run on jdk21. Result is :
{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
but was:
[ERROR]
CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
expected: but was:
[ERROR]
CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
expected: but was:
[ERROR]
CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
expected: but was:
[ERROR]
CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
expected: but was:
[ERROR]
CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
expected: but was:
[ERROR]
CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
expected: but was:
[ERROR]
CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
expected: but was:
[ERROR]
CacheConfigImplTest.testRemoveSaveFinalEnabledByUserProperty:436->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalEnabledByUserProperty$51:439
expected: but was:
[ERROR]
CacheConfigImplTest.testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled:455->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled$54:457
expected: but was:
[INFO]
[ERROR] Tests run: 71, Failures: 10, Errors: 0, Skipped: 4
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
{code}
In class "CacheConfigImplTest", a method "deepMockConfigFile" mocks the result
of the call to java.nio.file.Files.exists (via
"FileSystemProvider.checkAccess").
In jdk21 version, "Files.exists" does not rely on the same underlying
"FileSystemProvider" method, therefore breaking the mocking purpose.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Add info [maven]
gnodet opened a new pull request, #1479: URL: https://github.com/apache/maven/pull/1479 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839834#comment-17839834
]
Rocher Suchard edited comment on MWRAPPER-133 at 4/22/24 8:28 PM:
--
{quote}so data from MAVEN_CONFIG will be duplicated on cmd by old wrapper{quote}
I will try to see what wrapper script really receive (I assume it should
contains something like {{-s }} but if this was really duplicated on
our jenkins, I would have no need for this issue (I don't have access to the
Jenkins plugin version).
was (Author: rocher.suchard):
{quote}so data from MAVEN_CONFIG will be duplicated on cmd by old wrapper{quote}
I will try to see what wrapper script really receive (I assume it should
MAVEN_CONFIG contains something like {{-s }} but if this was really
duplicated on our jenkins, I would have no need for this issue (I don't have
access to the Jenkins plugin version).
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839834#comment-17839834
]
Rocher Suchard commented on MWRAPPER-133:
-
{quote}so data from MAVEN_CONFIG will be duplicated on cmd by old wrapper{quote}
I will try to see what wrapper script really receive (I assume it should
MAVEN_CONFIG contains something like {{-s }} but if this was really
duplicated on our jenkins, I would have no need for this issue (I don't have
access to the Jenkins plugin version).
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Fix link in issueManagement in docs [maven-parent]
slawekjaranowski opened a new pull request, #177: URL: https://github.com/apache/maven-parent/pull/177 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Default value must be manually handled [maven-mvnd]
gnodet commented on PR #953: URL: https://github.com/apache/maven-mvnd/pull/953#issuecomment-2070825470 > @gnodet If you run this PR locally: > > * it will pass ok, but > * maven-conf-ignore-ext IT is **wrong**: maven.conf where ignore is, is not observed by mvnd. Also local repository will show that extension foo:bar is attempted to resolve, but naturally unsuccessfully > * this means that mvnd happily goes along instead to fail (as it failed to resolve the extension) > > Any idea? Yes, the problem is here: * https://github.com/apache/maven-mvnd/blob/dc4179fc3ba193e18d84dc090abfe336649d63ed/daemon-m40/src/main/java/org/apache/maven/cli/DaemonMavenCli.java#L699 * https://github.com/apache/maven-mvnd/blob/dc4179fc3ba193e18d84dc090abfe336649d63ed/daemon-m39/src/main/java/org/apache/maven/cli/DaemonMavenCli.java#L615 A failure to resolve the extension simply prints a warning and ignore That should be fixed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Fix link in issueManagement in docs [maven-apache-parent]
slawekjaranowski opened a new pull request, #219: URL: https://github.com/apache/maven-apache-parent/pull/219 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839827#comment-17839827 ] ASF GitHub Bot commented on MCOMPILER-515: -- hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070771711 Great, so we have 2 buckets to break these issues into. 1) issues with the difference in behavior with javac (vs JDT) and 2) issues with the difference in behavior with this plugin and the Takari one. I'm curious, what are the issues in the first bucket? Perhaps the target should be to get the maven compiler to work on JDT as a requirement instead of javac and JDT. Maybe that's a goal we can achieve. On Monday, April 22, 2024 at 12:21:17 PM PDT, Tamas Cservenak ***@***.***> wrote: Today, if one needs fully incremental (and build avoidance) with current stable Maven 3.9.x, one should use Takari Lifecycle plugin. But even then you should use Eclipse JDT not javac. But, in turn, with JDT, you get other nice things like enforcing dependency usage and so on... http://takari.io/book/index.html — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070771711 Great, so we have 2 buckets to break these issues into. 1) issues with the difference in behavior with javac (vs JDT) and 2) issues with the difference in behavior with this plugin and the Takari one. I'm curious, what are the issues in the first bucket? Perhaps the target should be to get the maven compiler to work on JDT as a requirement instead of javac and JDT. Maybe that's a goal we can achieve. On Monday, April 22, 2024 at 12:21:17 PM PDT, Tamas Cservenak ***@***.***> wrote: Today, if one needs fully incremental (and build avoidance) with current stable Maven 3.9.x, one should use Takari Lifecycle plugin. But even then you should use Eclipse JDT not javac. But, in turn, with JDT, you get other nice things like enforcing dependency usage and so on... http://takari.io/book/index.html — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839826#comment-17839826 ] ASF GitHub Bot commented on MCOMPILER-515: -- cstamas commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070735050 Today, if one needs _fully incremental (and build avoidance) with current stable Maven 3.9.x, one should use Takari Lifecycle plugin_. But even then you should use Eclipse JDT not javac. But, in turn, with JDT, you get other nice things like enforcing dependency usage and so on... http://takari.io/book/index.html > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
cstamas commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070735050 Today, if one needs _fully incremental (and build avoidance) with current stable Maven 3.9.x, one should use Takari Lifecycle plugin_. But even then you should use Eclipse JDT not javac. But, in turn, with JDT, you get other nice things like enforcing dependency usage and so on... http://takari.io/book/index.html -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839825#comment-17839825 ] ASF GitHub Bot commented on MCOMPILER-515: -- hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070717803 I agree. I am asking if there is a way we can relax the feature/requirement to make it easier to implement and maintain. On Monday, April 22, 2024 at 12:07:46 PM PDT, Tamas Cservenak ***@***.***> wrote: I agree that "incremental" is very important feature. My stance is that this implementation is bad/wrong. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070717803 I agree. I am asking if there is a way we can relax the feature/requirement to make it easier to implement and maintain. On Monday, April 22, 2024 at 12:07:46 PM PDT, Tamas Cservenak ***@***.***> wrote: I agree that "incremental" is very important feature. My stance is that this implementation is bad/wrong. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839824#comment-17839824 ] ASF GitHub Bot commented on MCOMPILER-515: -- cstamas commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070692585 I agree that "incremental" is very important feature. My stance is that _this implementation_ is bad/wrong. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
cstamas commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070692585 I agree that "incremental" is very important feature. My stance is that _this implementation_ is bad/wrong. -- 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-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839823#comment-17839823
]
Slawomir Jaranowski commented on MWRAPPER-133:
--
By the way code from jenkins:
{code:java}
envOverride.put("MAVEN_CONFIG", mavenConfig.toString());
...
String content = generateMavenWrapperScriptContent(mvnExec,
mavenConfig.toString());
// and in generateMavenWrapperScriptContent
script.append("\"")
.append(mvnExec.getRemote())
.append("\" ")
.append(mavenConfig)
.append(" \"$@\"")
.append(lineSep);
{code}
so data from {{MAVEN_CONFIG}} will be duplicated on cmd by old wrapper
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-515) Plugin is NOT incremental, so let it go
[ https://issues.apache.org/jira/browse/MCOMPILER-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839822#comment-17839822 ] ASF GitHub Bot commented on MCOMPILER-515: -- hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070683052 Incremental building is an important feature. If you need it, you need it. Most projects don't but some very important projects do and they need something like this the most. I think the right solution is a compromise where we scale back how this works. The problem is that computing the right set of code to recompile is hard. So let's just make that part easy. Perhaps make the incremental based upon something higher level that where we are now. If that's not possible, then the solution is to actually maintain a map of files to classes to dependent classes/files from the last build and to use that to compute what is built. I think that is the buggy part as that that map is hard to maintain. Perhaps make that map manually editable by devs. We only need this feature in dev environments anyway. TLDR This is an important feature so let's find a way to reduce the complexity to make it work and be maintainable. > Plugin is NOT incremental, so let it go > --- > > Key: MCOMPILER-515 > URL: https://issues.apache.org/jira/browse/MCOMPILER-515 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > > The maven-compiler-plugin is NOT incremental, so we should just let it go. > The shared incremental stuff is broken since it's last factual code change > (2012!). > Moreover, the broken incremental stuff just makes us look bad, see the "mvn > clean install" vs "mvn verify" issue: > [https://www.youtube.com/watch?v=XeQj-IbSxJI] > Accept it, that this plugins is not incremental, so it should not make users > believe it is. Moreover, the bugs in this feature exist for too long, that > just cause harm to users and to project as whole. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-515] This plugin is not "incremental" [maven-compiler-plugin]
hunterpayne commented on PR #160: URL: https://github.com/apache/maven-compiler-plugin/pull/160#issuecomment-2070683052 Incremental building is an important feature. If you need it, you need it. Most projects don't but some very important projects do and they need something like this the most. I think the right solution is a compromise where we scale back how this works. The problem is that computing the right set of code to recompile is hard. So let's just make that part easy. Perhaps make the incremental based upon something higher level that where we are now. If that's not possible, then the solution is to actually maintain a map of files to classes to dependent classes/files from the last build and to use that to compute what is built. I think that is the buggy part as that that map is hard to maintain. Perhaps make that map manually editable by devs. We only need this feature in dev environments anyway. TLDR This is an important feature so let's find a way to reduce the complexity to make it work and be maintainable. -- 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-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839815#comment-17839815
]
Tamas Cservenak commented on MWRAPPER-133:
--
Seems this variable was invented by Takari wrapper, and was "legacy" already
when project moved to ASF. I found this issue
[https://issues.jenkins.io/browse/JENKINS-47890]
and related https://github.com/takari/maven-wrapper/issues/128
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839808#comment-17839808
]
Rocher Suchard edited comment on MWRAPPER-133 at 4/22/24 6:16 PM:
--
[~sjaranowski] I don't know the history behind Jenkins Maven Pipeline and Maven
Wrapper but the MAVEN_CONFIG is not something from Maven, but something found
in the wrapper script directly (I do not check the cmd part because even as a
Windows user, I loath to use batch and cmd file :)) :
{code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=bin}
# shellcheck disable=SC2086 # safe args
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
{code}
versus
{code:bash|title=mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6}
exec_maven() {
unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || :
exec "$MAVEN_HOME/bin/$MVN_CMD" "$@" || die "cannot exec
$MAVEN_HOME/bin/$MVN_CMD"
}
{code}
As show above, {{$MAVEN_CONFIG}} is not there but it is present in the wrapper
script in 3.2.0 :
{code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=script}
# shellcheck disable=SC2086 # safe args
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
{code}
If there is a maven alternative (MAVEN_ARGS) why not, but from user standpoint,
removing MAVEN_CONFIG is forcing user to
1) either stay with maven wrapper 3.2.0
2) either upgrade Jenkins or its maven pipeline (or other kind of pipeline) =
complicated.
was (Author: rocher.suchard):
[~sjaranowski] I don't know the history behind Jenkins Maven Pipeline and Maven
Wrapper but the MAVEN_CONFIG is not something from Maven, but something found
in the wrapper script directly (I do not check the cmd part because even as a
Windows user, I loath to use batch and cmd file :)) :
{code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=bin}
# shellcheck disable=SC2086 # safe args
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
{code}
versus
{code:bash|title=mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6}
exec_maven() {
unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || :
exec "$MAVEN_HOME/bin/$MVN_CMD" "$@" || die "cannot exec
$MAVEN_HOME/bin/$MVN_CMD"
}
{code}
The {{$MAVEN_CONFIG}} is not there but it is present in the wrapper script in
3.2.0 :
{code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=script}
# shellcheck disable=SC2086 # safe args
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
{code}
If there is a maven alternative (MAVEN_ARGS) why not, but from user standpoint,
removing MAVEN_CONFIG is forcing user to
1) either stay with maven wrapper 3.2.0
2) either upgrade Jenkins or its maven pipeline (or other kind of pipeline) =
complicated.
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER}
[jira] [Commented] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839808#comment-17839808
]
Rocher Suchard commented on MWRAPPER-133:
-
[~sjaranowski] I don't know the history behind Jenkins Maven Pipeline and Maven
Wrapper but the MAVEN_CONFIG is not something from Maven, but something found
in the wrapper script directly (I do not check the cmd part because even as a
Windows user, I loath to use batch and cmd file :)) :
{code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=bin}
# shellcheck disable=SC2086 # safe args
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
{code}
versus
{code:bash|title=mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6}
exec_maven() {
unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || :
exec "$MAVEN_HOME/bin/$MVN_CMD" "$@" || die "cannot exec
$MAVEN_HOME/bin/$MVN_CMD"
}
{code}
The {{$MAVEN_CONFIG}} is not there but it is present in the wrapper script in
3.2.0 :
{code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=script}
# shellcheck disable=SC2086 # safe args
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
{code}
If there is a maven alternative (MAVEN_ARGS) why not, but from user standpoint,
removing MAVEN_CONFIG is forcing user to
1) either stay with maven wrapper 3.2.0
2) either upgrade Jenkins or its maven pipeline (or other kind of pipeline) =
complicated.
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Default value must be manually handled [maven-mvnd]
cstamas commented on PR #953: URL: https://github.com/apache/maven-mvnd/pull/953#issuecomment-2070176626 @gnodet If you run this PR locally: * it will pass ok, but * maven-conf-ignore-ext IT is **wrong**: maven.conf where ignore is, is not observed by mvnd. Also local repository will show that extension foo:bar is attempted to resolve, but naturally unsuccessfully * this means that mvnd happily goes along instead to fail (as it failed to resolve the extension) Any idea? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Default value must be manually handled [maven-mvnd]
cstamas commented on PR #953: URL: https://github.com/apache/maven-mvnd/pull/953#issuecomment-2070153385 Sure, this will be in it. But as i wrote, seems there is something else to be fixed as IT this PR adds shows... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Default value must be manually handled [maven-mvnd]
wendigo commented on PR #953: URL: https://github.com/apache/maven-mvnd/pull/953#issuecomment-2070141407 Can we get this in for alpha14? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MWRAPPER-134.
Resolution: Fixed
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the {{mvnw}} / \{{mvnw.cmd}} scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839771#comment-17839771
]
ASF GitHub Bot commented on MWRAPPER-134:
-
cstamas merged PR #135:
URL: https://github.com/apache/maven-wrapper/pull/135
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the {{mvnw}} / \{{mvnw.cmd}} scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MWRAPPER-134] Add wrapperVersion to maven-wrapper.properties [maven-wrapper]
cstamas merged PR #135: URL: https://github.com/apache/maven-wrapper/pull/135 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.maven.plugins:maven-jar-plugin from 3.4.0 to 3.4.1 [maven-apache-parent]
CrazyHZM merged PR #217: URL: https://github.com/apache/maven-apache-parent/pull/217 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated MBUILDCACHE-87:
--
Labels: pull-request-available (was: )
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839741#comment-17839741
]
ASF GitHub Bot commented on MBUILDCACHE-87:
---
reda-alaoui opened a new pull request, #146:
URL: https://github.com/apache/maven-build-cache-extension/pull/146
Following this checklist to help us incorporate your
contribution quickly and easily:
- [X] Make sure there is a [MBUILDCACHE JIRA
issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line
and body.
- [X] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [X] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [X] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [X] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [X] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MBUILDCACHE-87] - Checksum should consider plugin dependencies [maven-build-cache-extension]
reda-alaoui opened a new pull request, #146: URL: https://github.com/apache/maven-build-cache-extension/pull/146 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [MBUILDCACHE JIRA issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nils Breunese updated MWRAPPER-134:
---
Description:
I use [Renovate|https://github.com/renovatebot/renovate] to automatically keep
dependencies up-to-date and I noticed that the upgrade to Maven Wrapper 3.3.0
removed the {{wrapperUrl}} line from
{{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
MWRAPPER-120.
A couple of my colleagues implemented the support for keeping Maven Wrapper
up-to-date in Renovate, and I believe Renovate currently determines the version
of Maven Wrapper based on the {{wrapperUrl}} property, so I think that logic
may need to be updated after this change. Without the {{wrapperUrl}} property,
I think currently the only option to determine the Maven Wrapper version is
parsing the {{mvnw}} / \{{mvnw.cmd}} scripts themselves, but that sounds like a
clunky and unreliable way.
In a discussion on the maven-users mailinglist, the idea was posted to add a
dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read by
external tools.
was:
I use [Renovate|https://github.com/renovatebot/renovate] to automatically keep
dependencies up-to-date and I noticed that the upgrade to Maven Wrapper 3.3.0
removed the {{wrapperUrl}} line from
{{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
MWRAPPER-120.
A couple of my colleagues implemented the support for keeping Maven Wrapper
up-to-date in Renovate, and I believe Renovate currently determines the version
of Maven Wrapper based on the {{wrapperUrl}} property, so I think that logic
may need to be updated after this change. Without the {{wrapperUrl}} property,
I think currently the only option to determine the Maven Wrapper version is
parsing the `mvnw` / `./mvnw.bat` scripts themselves, but that sounds like a
clunky and unreliable way.
In a discussion on the maven-users mailinglist, the idea was posted to add a
dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read by
external tools.
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the {{mvnw}} / \{{mvnw.cmd}} scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839722#comment-17839722
]
ASF GitHub Bot commented on MWRAPPER-134:
-
breun commented on PR #135:
URL: https://github.com/apache/maven-wrapper/pull/135#issuecomment-2069725218
@cstamas Thanks, I think this should work!
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the `mvnw` / `./mvnw.bat` scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MWRAPPER-134] Add wrapperVersion to maven-wrapper.properties [maven-wrapper]
breun commented on PR #135: URL: https://github.com/apache/maven-wrapper/pull/135#issuecomment-2069725218 @cstamas Thanks, I think this should work! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Upgrade JLine to 3.26.0 [maven]
cstamas commented on PR #1478: URL: https://github.com/apache/maven/pull/1478#issuecomment-2069679049 ? Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.jline:jline:jar:3.26.0 in central Sync pending? -- 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-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839675#comment-17839675
]
ASF GitHub Bot commented on MWRAPPER-134:
-
cstamas commented on PR #135:
URL: https://github.com/apache/maven-wrapper/pull/135#issuecomment-2069595291
@breun ping
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the `mvnw` / `./mvnw.bat` scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MWRAPPER-134] Add wrapperVersion to maven-wrapper.properties [maven-wrapper]
cstamas commented on PR #135: URL: https://github.com/apache/maven-wrapper/pull/135#issuecomment-2069595291 @breun ping -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MWRAPPER-134:
-
Component/s: Maven Wrapper Plugin
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Plugin
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the `mvnw` / `./mvnw.bat` scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839673#comment-17839673
]
ASF GitHub Bot commented on MWRAPPER-134:
-
cstamas opened a new pull request, #135:
URL: https://github.com/apache/maven-wrapper/pull/135
That contains the current version of the deployed Maven Wrapper
---
https://issues.apache.org/jira/browse/MWRAPPER-134
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the `mvnw` / `./mvnw.bat` scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MWRAPPER-134] Add wrapperVersion to maven-wrapper.properties [maven-wrapper]
cstamas opened a new pull request, #135: URL: https://github.com/apache/maven-wrapper/pull/135 That contains the current version of the deployed Maven Wrapper --- https://issues.apache.org/jira/browse/MWRAPPER-134 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MWRAPPER-134:
Assignee: Tamas Cservenak
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Assignee: Tamas Cservenak
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the `mvnw` / `./mvnw.bat` scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Fix split package in org.apache.maven.api.di [maven]
gnodet merged PR #1455: URL: https://github.com/apache/maven/pull/1455 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MBUILDCACHE-87) Checksum should consider plugin dependencies
Réda Housni Alaoui created MBUILDCACHE-87:
-
Summary: Checksum should consider plugin dependencies
Key: MBUILDCACHE-87
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
Project: Maven Build Cache Extension
Issue Type: Improvement
Reporter: Réda Housni Alaoui
I have a multi module project where module A is used as a dependency of
maven-dependency-plugin:unpack declared in module B.
{buildinfo.xml} of module B does not consider module A as a dependency.
Maybe something similar to
https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Réda Housni Alaoui updated MBUILDCACHE-87:
--
Description:
I have a multi module project where module A is used as a dependency of
maven-dependency-plugin:unpack declared in module B.
{{buildinfo.xml}} of module B does not consider module A as a dependency.
Maybe something similar to
https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
should be added for plugin dependencies?
was:
I have a multi module project where module A is used as a dependency of
maven-dependency-plugin:unpack declared in module B.
{buildinfo.xml} of module B does not consider module A as a dependency.
Maybe something similar to
https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
should be added for plugin dependencies?
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8081) default profile activation should consider available system and user properties
[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839658#comment-17839658
]
ASF GitHub Bot commented on MNG-8081:
-
mbenson commented on PR #1477:
URL: https://github.com/apache/maven/pull/1477#issuecomment-2069413063
Sorry @cstamas, was working late and apparently not 100%. Edited my comment
with changed text in bold.
> default profile activation should consider available system and user
> properties
> ---
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.9.6, 4.0.0
>Reporter: Matthew Jason Benson
>Priority: Minor
> Fix For: 3.9.7, 4.0.0, 4.0.0-alpha-14
>
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
>
>
> env.FOO
> ${env.BAR}
>
> {code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8081] Profile property activation interpolation [maven]
mbenson commented on PR #1477: URL: https://github.com/apache/maven/pull/1477#issuecomment-2069413063 Sorry @cstamas, was working late and apparently not 100%. Edited my comment with changed text in bold. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
[
https://issues.apache.org/jira/browse/MWRAPPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MWRAPPER-134:
-
Fix Version/s: 3.3.1
> Provide a reliable way to determine the Maven Wrapper version
> -
>
> Key: MWRAPPER-134
> URL: https://issues.apache.org/jira/browse/MWRAPPER-134
> Project: Maven Wrapper
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Nils Breunese
>Priority: Normal
> Fix For: 3.3.1
>
>
> I use [Renovate|https://github.com/renovatebot/renovate] to automatically
> keep dependencies up-to-date and I noticed that the upgrade to Maven Wrapper
> 3.3.0 removed the {{wrapperUrl}} line from
> {{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
> MWRAPPER-120.
> A couple of my colleagues implemented the support for keeping Maven Wrapper
> up-to-date in Renovate, and I believe Renovate currently determines the
> version of Maven Wrapper based on the {{wrapperUrl}} property, so I think
> that logic may need to be updated after this change. Without the
> {{wrapperUrl}} property, I think currently the only option to determine the
> Maven Wrapper version is parsing the `mvnw` / `./mvnw.bat` scripts
> themselves, but that sounds like a clunky and unreliable way.
> In a discussion on the maven-users mailinglist, the idea was posted to add a
> dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read
> by external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-134) Provide a reliable way to determine the Maven Wrapper version
Nils Breunese created MWRAPPER-134:
--
Summary: Provide a reliable way to determine the Maven Wrapper
version
Key: MWRAPPER-134
URL: https://issues.apache.org/jira/browse/MWRAPPER-134
Project: Maven Wrapper
Issue Type: Improvement
Affects Versions: 3.3.0
Reporter: Nils Breunese
I use [Renovate|https://github.com/renovatebot/renovate] to automatically keep
dependencies up-to-date and I noticed that the upgrade to Maven Wrapper 3.3.0
removed the {{wrapperUrl}} line from
{{{}.mvn/wrapper/maven-wrapper.properties{}}}. I guess that is related to
MWRAPPER-120.
A couple of my colleagues implemented the support for keeping Maven Wrapper
up-to-date in Renovate, and I believe Renovate currently determines the version
of Maven Wrapper based on the {{wrapperUrl}} property, so I think that logic
may need to be updated after this change. Without the {{wrapperUrl}} property,
I think currently the only option to determine the Maven Wrapper version is
parsing the `mvnw` / `./mvnw.bat` scripts themselves, but that sounds like a
clunky and unreliable way.
In a discussion on the maven-users mailinglist, the idea was posted to add a
dedicated property for this (e.g. {{{}wrapperVersion{}}}), which can be read by
external tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8081) default profile activation should consider available system and user properties
[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839610#comment-17839610
]
ASF GitHub Bot commented on MNG-8081:
-
cstamas commented on PR #1477:
URL: https://github.com/apache/maven/pull/1477#issuecomment-2069092211
@mbenson can you clarify what you mean by "only [...] property activations"
vs "all property activations" as I think don't understand it fully...
> default profile activation should consider available system and user
> properties
> ---
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.9.6, 4.0.0
>Reporter: Matthew Jason Benson
>Priority: Minor
> Fix For: 3.9.7, 4.0.0, 4.0.0-alpha-14
>
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
>
>
> env.FOO
> ${env.BAR}
>
> {code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8081] Profile property activation interpolation [maven]
cstamas commented on PR #1477: URL: https://github.com/apache/maven/pull/1477#issuecomment-2069092211 @mbenson can you clarify what you mean by "only [...] property activations" vs "all property activations" as I think don't understand it fully... -- 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] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839607#comment-17839607
]
Slawomir Jaranowski edited comment on MWRAPPER-133 at 4/22/24 10:49 AM:
{{MAVEN_CONFIG}} looks like undocumented feature in 3.x we have
{{MAVEN_ARGS}} in 3.9.x and 4.x
{{script-only}} simply call destination maven script so should it works
https://maven.apache.org/configure.html
was (Author: slawekjaranowski):
{{MAVEN_CONFIG}} looks like undocumented feature in 3.x we have
{{MAVEN_ARGS}} in 3.9.x and 4.x
{{script-only}} simply call destination maven script so should it works
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[
https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839607#comment-17839607
]
Slawomir Jaranowski commented on MWRAPPER-133:
--
{{MAVEN_CONFIG}} looks like undocumented feature in 3.x we have
{{MAVEN_ARGS}} in 3.9.x and 4.x
{{script-only}} simply call destination maven script so should it works
> MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
> ---
>
> Key: MWRAPPER-133
> URL: https://issues.apache.org/jira/browse/MWRAPPER-133
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.3.0
>Reporter: Rocher Suchard
>Priority: Major
>
> Hello,
> Due to an update by Renovate in one of our project, I've seen some error
> related to internal dependencies not being picked up by Maven : while we were
> using a custom settings, it did not use it and was using Central instead of
> our Artifactory.
> Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG
> environnement variable here :
> https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
> The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and
> I've played around with the default value and type:
> {code:bash}
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
> # use scripts-only
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> # nothing
> $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
> # use bin
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
> $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
> ...
> [INFO] Unpacked bin type wrapper distribution
> org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
> [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6
> and download from https://repo.maven.apache.org/maven2
> ...
> $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
> mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
> mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
> mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
> {code}
> Is there a way to do the same for the script-only if this is to be the
> default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
Rocher Suchard created MWRAPPER-133:
---
Summary: MAVEN_CONFIG populated by Jenkins Maven Pipeline is no
longer read,
Key: MWRAPPER-133
URL: https://issues.apache.org/jira/browse/MWRAPPER-133
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Scripts
Affects Versions: 3.3.0
Reporter: Rocher Suchard
Hello,
Due to an update by Renovate in one of our project, I've seen some error
related to internal dependencies not being picked up by Maven : while we were
using a custom settings, it did not use it and was using Central instead of our
Artifactory.
Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG environnement
variable here :
https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400
The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and I've
played around with the default value and type:
{code:bash}
$ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6
# use scripts-only
$ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
# nothing
$ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6
# use bin
$ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %
$ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin
...
[INFO] Unpacked bin type wrapper distribution
org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0
[INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6 and
download from https://repo.maven.apache.org/maven2
...
$ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/
mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*"
mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"
mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %*
{code}
Is there a way to do the same for the script-only if this is to be the default ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Upgrade to alpha 14 [maven-mvnd]
gnodet opened a new pull request, #965: URL: https://github.com/apache/maven-mvnd/pull/965 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.apache.maven.resolver:maven-resolver-transport-http from 1.9.18 to 1.9.19 [maven-build-cache-extension]
dependabot[bot] opened a new pull request, #145: URL: https://github.com/apache/maven-build-cache-extension/pull/145 Bumps org.apache.maven.resolver:maven-resolver-transport-http from 1.9.18 to 1.9.19. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Upgrade develocity [maven-mvnd]
gnodet commented on PR #952: URL: https://github.com/apache/maven-mvnd/pull/952#issuecomment-2068687502 So the XML config needs to be updated as well ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump resolverVersion from 1.9.18 to 1.9.19 [maven-resolver-ant-tasks]
dependabot[bot] opened a new pull request, #38: URL: https://github.com/apache/maven-resolver-ant-tasks/pull/38 Bumps `resolverVersion` from 1.9.18 to 1.9.19. Updates `org.apache.maven.resolver:maven-resolver-api` from 1.9.18 to 1.9.19 Release notes Sourced from https://github.com/apache/maven-resolver/releases;>org.apache.maven.resolver:maven-resolver-api's releases. 1.9.19 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628version=12353946;>Release Notes - Maven Resolver - Version 1.9.19 What's Changed [1.9.x][MRESOLVER-483] Fix path concatenation logic by https://github.com/cstamas;>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/420;>apache/maven-resolver#420 [1.9.x] [MRESOLVER-522] Improve congested file locks behaviour (https://redirect.github.com/apache/maven-resolver/issues/455;>#455) by https://github.com/cstamas;>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/461;>apache/maven-resolver#461 [1.9.x] Update dependencies by https://github.com/cstamas;>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/462;>apache/maven-resolver#462 [1.9.x] [MRESOLVER-536] Do not belly up if FS does not support setting mtime by https://github.com/cstamas;>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/469;>apache/maven-resolver#469 Full Changelog: https://github.com/apache/maven-resolver/compare/maven-resolver-1.9.18...maven-resolver-1.9.19;>https://github.com/apache/maven-resolver/compare/maven-resolver-1.9.18...maven-resolver-1.9.19 Commits https://github.com/apache/maven-resolver/commit/c1b03574961fd2daa7a678bb3fbf9f0779afee56;>c1b0357 [maven-release-plugin] prepare release maven-resolver-1.9.19 https://github.com/apache/maven-resolver/commit/adadd42d1642f39bafedb2ddd619b044fecb12b0;>adadd42 [MRESOLVER-536] Do not belly up if FS does not support setting mtime (https://redirect.github.com/apache/maven-resolver/issues/469;>#469) https://github.com/apache/maven-resolver/commit/31df8a3dc503895172d277de56b1c4a53da0a27c;>31df8a3 [1.9.x] Update dependencies (https://redirect.github.com/apache/maven-resolver/issues/462;>#462) https://github.com/apache/maven-resolver/commit/b225076e5d5b2fe3f166a4018802ac94b7cc94f7;>b225076 [MRESOLVER-522] Improve congested file locks behaviour (https://redirect.github.com/apache/maven-resolver/issues/455;>#455) (https://redirect.github.com/apache/maven-resolver/issues/461;>#461) https://github.com/apache/maven-resolver/commit/fc969c2570041bb72c3f0141ff4957e8754f365c;>fc969c2 [1.9.x][MRESOLVER-483] Fix path concatenation logic (https://redirect.github.com/apache/maven-resolver/issues/420;>#420) https://github.com/apache/maven-resolver/commit/a3e620d6d2ab6ca58d42d264347341b31da00dde;>a3e620d Use one Maven in CI https://github.com/apache/maven-resolver/commit/fff4bdf92fe10937975623db27a69ced5d1efcd1;>fff4bdf [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-resolver/compare/maven-resolver-1.9.18...maven-resolver-1.9.19;>compare view Updates `org.apache.maven.resolver:maven-resolver-util` from 1.9.18 to 1.9.19 Release notes Sourced from https://github.com/apache/maven-resolver/releases;>org.apache.maven.resolver:maven-resolver-util's releases. 1.9.19 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628version=12353946;>Release Notes - Maven Resolver - Version 1.9.19 What's Changed [1.9.x][MRESOLVER-483] Fix path concatenation logic by https://github.com/cstamas;>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/420;>apache/maven-resolver#420 [1.9.x] [MRESOLVER-522] Improve congested file locks behaviour (https://redirect.github.com/apache/maven-resolver/issues/455;>#455) by https://github.com/cstamas;>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/461;>apache/maven-resolver#461 [1.9.x] Update dependencies by https://github.com/cstamas;>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/462;>apache/maven-resolver#462 [1.9.x] [MRESOLVER-536] Do not belly up if FS does not support setting mtime by https://github.com/cstamas;>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/469;>apache/maven-resolver#469 Full Changelog: https://github.com/apache/maven-resolver/compare/maven-resolver-1.9.18...maven-resolver-1.9.19;>https://github.com/apache/maven-resolver/compare/maven-resolver-1.9.18...maven-resolver-1.9.19 Commits https://github.com/apache/maven-resolver/commit/c1b03574961fd2daa7a678bb3fbf9f0779afee56;>c1b0357 [maven-release-plugin] prepare release maven-resolver-1.9.19 https://github.com/apache/maven-resolver/commit/adadd42d1642f39bafedb2ddd619b044fecb12b0;>adadd42 [MRESOLVER-536] Do not belly up if FS does
