[jira] [Updated] (MASSEMBLY-1030) Manifest entries from archive configuration are not added
[
https://issues.apache.org/jira/browse/MASSEMBLY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MASSEMBLY-1030:
Description:
given the follow configuration
{code:java}
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
{code}
he entries from manifestEntries are not added to MANIFEST file
was:
given the follow configuration
{{
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
}}
the entries from manifestEntries are not added to MANIFEST file
> Manifest entries from archive configuration are not added
> --
>
> Key: MASSEMBLY-1030
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1030
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 3.7.1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.2
>
>
> given the follow configuration
> {code:java}
>
>
> src/main/assembly/web-bundle.xml
>
>
>
> ${project.build.outputDirectory}/META-INF/MANIFEST.MF
>
> ee10
>
>
> merge
> {code}
> he entries from manifestEntries are not added to MANIFEST file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-1030) Manifest entries from archive configuration are not added
[
https://issues.apache.org/jira/browse/MASSEMBLY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MASSEMBLY-1030:
Description:
given the follow configuration
{{
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
}}
the entries from manifestEntries are not added to MANIFEST file
was:
given the follow configuration
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
the entries from manifestEntries are not added to MANIFEST file
> Manifest entries from archive configuration are not added
> --
>
> Key: MASSEMBLY-1030
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1030
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 3.7.1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.2
>
>
> given the follow configuration
> {{
>
> src/main/assembly/web-bundle.xml
>
>
>
> ${project.build.outputDirectory}/META-INF/MANIFEST.MF
>
> ee10
>
>
> merge
> }}
> the entries from manifestEntries are not added to MANIFEST file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MASSEMBLY-1030) Manifest entries from archive configuration are not added
Olivier Lamy created MASSEMBLY-1030:
---
Summary: Manifest entries from archive configuration are not added
Key: MASSEMBLY-1030
URL: https://issues.apache.org/jira/browse/MASSEMBLY-1030
Project: Maven Assembly Plugin
Issue Type: Bug
Components: manifest
Affects Versions: 3.7.1
Reporter: Olivier Lamy
Assignee: Olivier Lamy
Fix For: 3.7.2
given the follow configuration
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
the entries from manifestEntries are not added to MANIFEST file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Bump org.apache.maven.resolver:maven-resolver-util from 1.4.1 to 1.9.20 [maven-invoker-plugin]
dependabot[bot] opened a new pull request, #239: URL: https://github.com/apache/maven-invoker-plugin/pull/239 Bumps [org.apache.maven.resolver:maven-resolver-util](https://github.com/apache/maven-resolver) from 1.4.1 to 1.9.20. Release notes Sourced from https://github.com/apache/maven-resolver/releases";>org.apache.maven.resolver:maven-resolver-util's releases. 1.9.20 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354578";>Release Notes - Maven Resolver - Version 1.9.20 What's Changed [MRESOLVER-547] Just use setVersion by https://github.com/cstamas";>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/483";>apache/maven-resolver#483 [MRESOLVER-549] Parent POM 42 by https://github.com/cstamas";>@cstamas in https://redirect.github.com/apache/maven-resolver/pull/484";>apache/maven-resolver#484 Full Changelog: https://github.com/apache/maven-resolver/compare/maven-resolver-1.9.19...maven-resolver-1.9.20";>https://github.com/apache/maven-resolver/compare/maven-resolver-1.9.19...maven-resolver-1.9.20 1.9.19 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12353946";>Release Notes - Maven Resolver - Version 1.9.19 ... (truncated) Commits https://github.com/apache/maven-resolver/commit/f5fbc245e64091a41ba0926a6958b98bf0b29eb3";>f5fbc24 [maven-release-plugin] prepare release maven-resolver-1.9.20 https://github.com/apache/maven-resolver/commit/446009d7073014a7d418a4b9637664a2f6d05c82";>446009d [MRESOLVER-549][MRESOLVER-550][MRESOLVER-551] Parent POM 42 (https://redirect.github.com/apache/maven-resolver/issues/484";>#484) https://github.com/apache/maven-resolver/commit/4f16d5ecd94f85e6e7d793e6b6b82f20c9afbf56";>4f16d5e [MRESOLVER-547] Just use setVersion (https://redirect.github.com/apache/maven-resolver/issues/483";>#483) https://github.com/apache/maven-resolver/commit/c1b24c699621930f4eb77721400f2f6c46930626";>c1b24c6 [maven-release-plugin] prepare for next development iteration 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 Additional commits viewable in https://github.com/apache/maven-resolver/compare/maven-resolver-1.4.1...maven-resolver-1.9.20";>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 - `@
[PR] Bump com.google.inject:guice from 6.0.0 to 7.0.0 [maven-mvnd]
dependabot[bot] opened a new pull request, #990:
URL: https://github.com/apache/maven-mvnd/pull/990
Bumps [com.google.inject:guice](https://github.com/google/guice) from 6.0.0
to 7.0.0.
Release notes
Sourced from https://github.com/google/guice/releases";>com.google.inject:guice's
releases.
Guice 7.0.0
See https://github.com/google/guice/wiki/Guice700";>https://github.com/google/guice/wiki/Guice700
for release notes.
Guice 7.0.0-rc1
See https://github.com/google/guice/wiki/Guice700";>https://github.com/google/guice/wiki/Guice700
for release notes.
Commits
https://github.com/google/guice/commit/b0e1d0fab0167cd555ab8d262333c1a32db7d492";>b0e1d0f
set 7.0.0 release #s.
https://github.com/google/guice/commit/f4a66b797ecc05d80406d6c8fb11e6cc0e5c6d21";>f4a66b7
Make error_prone_annotations dependency optional
https://github.com/google/guice/commit/654032a954d55a00fc5ee90da815da98cb6676a1";>654032a
Internal change.
https://github.com/google/guice/commit/bee813b7cc15e46695ca1baf5041a00e0a612f91";>bee813b
Improve MissingImplementationError to lazily calculate suggestions and
standa...
https://github.com/google/guice/commit/2d64067e99401e50404c6e05a819bce891b725de";>2d64067
Use linked bindings for MapBinder/Multibinder/OptionalBinder aliases,
instead...
https://github.com/google/guice/commit/be0141cc0d01763a13ec0b2fcd32ddbe0748ad6d";>be0141c
Internal change
https://github.com/google/guice/commit/40a5bcfab5cfe45c3b6c5ffc9309b310df82775b";>40a5bcf
Avoid re-initializing factories that are already initialized. This is
necessa...
https://github.com/google/guice/commit/9ac476784e88f4481f8211dcb19ac536f5f2b32d";>9ac4767
Change the way we reference what 6.0 supports in the README, so it doesn't
ge...
https://github.com/google/guice/commit/24324ca6c61f64872376ed7f4ed22a3f1f0724f1";>24324ca
Prepare for the Guice 6.0 & 7.0 releases. This change does the
following:
https://github.com/google/guice/commit/49b1a33c594fd92ad0d1d013fa91d689e8814a6c";>49b1a33
Remove redundant references to javax.{inject,persistence,servlet} and
replace...
See full diff in https://github.com/google/guice/compare/6.0.0...7.0.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 ca.vanzyl.provisio.maven.plugins:provisio-maven-plugin from 1.0.24 to 1.0.25 [maven-mvnd]
dependabot[bot] opened a new pull request, #989: URL: https://github.com/apache/maven-mvnd/pull/989 Bumps [ca.vanzyl.provisio.maven.plugins:provisio-maven-plugin](https://github.com/takari/provisio) from 1.0.24 to 1.0.25. Release notes Sourced from https://github.com/takari/provisio/releases";>ca.vanzyl.provisio.maven.plugins:provisio-maven-plugin's releases. provisio-1.0.25 What's Changed Bump com.github.spullara.mustache.java:compiler from 0.9.11 to 0.9.13 by https://github.com/dependabot";>@dependabot in https://redirect.github.com/jvanzyl/provisio/pull/94";>jvanzyl/provisio#94 Updates by https://github.com/cstamas";>@cstamas in https://redirect.github.com/jvanzyl/provisio/pull/95";>jvanzyl/provisio#95 Full Changelog: https://github.com/jvanzyl/provisio/compare/provisio-1.0.24...provisio-1.0.25";>https://github.com/jvanzyl/provisio/compare/provisio-1.0.24...provisio-1.0.25 Commits https://github.com/jvanzyl/provisio/commit/9cbd1f87aecf431c87f66d75539900ecc0ae397c";>9cbd1f8 [maven-release-plugin] prepare release provisio-1.0.25 https://github.com/jvanzyl/provisio/commit/714af0ea70eda8aaa1f4409c352857294db830cd";>714af0e Updates https://github.com/jvanzyl/provisio/commit/bfcdd56a7c935322c53556a66d1bbba24f92277f";>bfcdd56 Bump com.github.spullara.mustache.java:compiler from 0.9.11 to 0.9.13 https://github.com/jvanzyl/provisio/commit/d4d61ce81b6bc426fda6a0f51b0d4bfe261fac2a";>d4d61ce [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/takari/provisio/compare/provisio-1.0.24...provisio-1.0.25";>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
Re: [PR] Bump info.picocli:picocli-codegen from 4.5.2 to 4.7.5 [maven-mvnd]
dependabot[bot] commented on PR #981: URL: https://github.com/apache/maven-mvnd/pull/981#issuecomment-2099717626 Superseded by #988. -- 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 info.picocli:picocli-codegen from 4.5.2 to 4.7.5 [maven-mvnd]
dependabot[bot] closed pull request #981: Bump info.picocli:picocli-codegen from 4.5.2 to 4.7.5 URL: https://github.com/apache/maven-mvnd/pull/981 -- 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 info.picocli:picocli-codegen from 4.5.2 to 4.7.6 [maven-mvnd]
dependabot[bot] opened a new pull request, #988: URL: https://github.com/apache/maven-mvnd/pull/988 Bumps [info.picocli:picocli-codegen](https://github.com/remkop/picocli) from 4.5.2 to 4.7.6. Release notes Sourced from https://github.com/remkop/picocli/releases";>info.picocli:picocli-codegen's releases. Picocli 4.7.6 Picocli 4.7.6 The picocli community is pleased to announce picocli 4.7.6. This release includes bugfixes and enhancements. Many thanks to the picocli community for raising these issues and providing the pull requests to address them! This is the eighty-fifth public release. Picocli follows https://semver.org/";>semantic versioning. Artifacts in this release are signed by Remko Popma (6601 E5C0 8DCC BB96). Table of Contents https://redirect.github.com/remkop/picocli/issues/4).7.6-new">New and noteworthy https://redirect.github.com/remkop/picocli/issues/4).7.6-fixes">Fixed issues https://redirect.github.com/remkop/picocli/issues/4).7.6-deprecated">Deprecations https://redirect.github.com/remkop/picocli/issues/4).7.6-breaking-changes">Potential breaking changes New and Noteworthy PropertiesDefaultProvider now tries to load properties from the classpath if the file cannot be found in the user.home directory. Fixed issues https://redirect.github.com/remkop/picocli/issues/2102";>#2102https://redirect.github.com/remkop/picocli/issues/2107";>#2107 Enhancement: PropertiesDefaultProvider should try to load properties from classpath (last). Thanks to https://github.com/rimuln";>Lumír Návrat for the pull request. https://redirect.github.com/remkop/picocli/issues/2202";>#2202 Enhancement: Change log level from WARN to INFO when bean not found in ApplicationContext. Thanks to https://github.com/dkirrane";>Desmond Kirrane for raising this. https://redirect.github.com/remkop/picocli/issues/2248";>#2248 Enhancement: Don't show hidden commands in JLine3 command description. Thanks to https://github.com/rehand";>Reinhard Handler for the pull request. https://redirect.github.com/remkop/picocli/issues/2170";>#2170 Enhancement: Use ... vararg instead of array parameter to match overridden method signature. Thanks to https://github.com/vorburger";>Michael Vorburger for the pull request. https://redirect.github.com/remkop/picocli/issues/2058";>#2058 Bugfix: defaultValue should not be applied in addition to user-specified value for options with a custom IParameterConsumer. Thanks to https://github.com/StaffanArvidsson";>Staffan Arvidsson McShane for raising this. https://redirect.github.com/remkop/picocli/issues/2148";>#2148 Bugfix: Fix NPE in jline3 Example.jar as ConfigurationPath cannot be null anymore. Thanks to https://github.com/llzen44";>llzen44 for the pull request. https://redirect.github.com/remkop/picocli/issues/2232";>#2232 Bugfix: fix bug for Optionalarguments with initial value. Thanks to https://github.com/hq6";>hq6 for raising this. https://redirect.github.com/remkop/picocli/issues/2149";>#2149 Bugfix: @Option-annotated setter method not invoked with default value when used in mixin for both command and subcommand. Thanks to https://github.com/JBWKZsf";>Zhonghao Wang for raising this. https://redirect.github.com/remkop/picocli/issues/2270";>#2270 Bugfix: Custom type converter for primitive boolean options should not be ignored. Thanks to https://codeberg.org/sven.k";>Sven Kammerer for raising this. https://redirect.github.com/remkop/picocli/issues/2234";>#2234 BUILD: fix errorprone TruthSelfEquals warnings https://redirect.github.com/remkop/picocli/issues/2172";>#2172 BUILD: Fix broken build. Thanks to https://github.com/vorburger";>Michael Vorburger for the pull request. https://redirect.github.com/remkop/picocli/issues/2174";>#2174 BUILD: Fix .gitattributes related CR/LF problems. Thanks to https://github.com/vorburger";>Michael Vorburger for the pull request. https://redirect.github.com/remkop/picocli/issues/2054";>#2054https://redirect.github.com/remkop/picocli/issues/2176";>#2176 BUILD: Add Error Prone. Thanks to https://github.com/vorburger";>Michael Vorburger for the pull request. https://redirect.github.com/remkop/picocli/issues/2053";>#2053 https://redirect.github.com/remkop/picocli/issues/2175";>#2175 CLEAN: Remove unused extra format arguments. Thanks to https://github.com/vorburger";>Michael Vorburger for the pull request. https://redirect.github.com/remkop/picocli/issues/2171";>#2171 DOC: Fix a few typos in CommandLine's JavaDoc. Thanks to https://github.com/vorburger";>Michael Vorburger for the pull request. https://redirect.github.com/remkop/picocli/issues/2217";>#2217 DOC: Clarify documentation for negatable options. Thanks to https://github.com/dbear496";>dbear496 for raising this. https://redirect.github.com/remkop/picocli/issues/2228";>#2228 DOC: Clarify that ParseResult passed to IExecutionException
[jira] [Closed] (MSHARED-971) System environment variable are always added to maven-invoker
[
https://issues.apache.org/jira/browse/MSHARED-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MSHARED-971.
---
Resolution: Fixed
> System environment variable are always added to maven-invoker
> -
>
> Key: MSHARED-971
> URL: https://issues.apache.org/jira/browse/MSHARED-971
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-invoker, maven-shared-utils
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Minor
> Fix For: maven-invoker-3.3.0
>
>
> In {{org.apache.maven.shared.invoker.MavenCommandLineBuilder}}
> [https://github.com/apache/maven-invoker/blob/d58703dd592ba0bc6f0a09928d0cce90e4002af9/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java#L197-L242]
> we have code:
> {code}
> if ( request.isShellEnvironmentInherited() )
> {
> cli.addSystemEnvironment();
> }
> {code}
> but in {{org.apache.maven.shared.utils.cli.Commandline}} we have:
> {code}
> public String[] getEnvironmentVariables()
> {
> addSystemEnvironment();
>...
> }
> {code}
> System environment variable are always added - it is inconsistent
> implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-971) System environment variable are always added to maven-invoker
[
https://issues.apache.org/jira/browse/MSHARED-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1784#comment-1784
]
ASF GitHub Bot commented on MSHARED-971:
slawekjaranowski merged PR #79:
URL: https://github.com/apache/maven-invoker/pull/79
> System environment variable are always added to maven-invoker
> -
>
> Key: MSHARED-971
> URL: https://issues.apache.org/jira/browse/MSHARED-971
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-invoker, maven-shared-utils
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Minor
> Fix For: maven-invoker-3.3.0
>
>
> In {{org.apache.maven.shared.invoker.MavenCommandLineBuilder}}
> [https://github.com/apache/maven-invoker/blob/d58703dd592ba0bc6f0a09928d0cce90e4002af9/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java#L197-L242]
> we have code:
> {code}
> if ( request.isShellEnvironmentInherited() )
> {
> cli.addSystemEnvironment();
> }
> {code}
> but in {{org.apache.maven.shared.utils.cli.Commandline}} we have:
> {code}
> public String[] getEnvironmentVariables()
> {
> addSystemEnvironment();
>...
> }
> {code}
> System environment variable are always added - it is inconsistent
> implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-971] Add test for inherited environment [maven-invoker]
slawekjaranowski merged PR #79: URL: https://github.com/apache/maven-invoker/pull/79 -- 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] (DOXIA-718) Apply best security recommendations to xml parsing and validation
[ https://issues.apache.org/jira/browse/DOXIA-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed DOXIA-718. -- Resolution: Not A Problem > Apply best security recommendations to xml parsing and validation > - > > Key: DOXIA-718 > URL: https://issues.apache.org/jira/browse/DOXIA-718 > Project: Maven Doxia > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Minor > > Apply OWASP recommendation if needed > > [https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIA-436) Remove xhtml-module dependency of markdown module
[ https://issues.apache.org/jira/browse/DOXIA-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed DOXIA-436. -- Resolution: Information Provided > Remove xhtml-module dependency of markdown module > - > > Key: DOXIA-436 > URL: https://issues.apache.org/jira/browse/DOXIA-436 > Project: Maven Doxia > Issue Type: Task > Components: Module - Markdown >Reporter: Lukas Theussl >Priority: Major > > The markdown parser in its original form (see DOXIA-426) uses the pegdown > library to get a whole html document which is then piped through the xhtml > parser to produce proper doxia events. This double-parsing should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIA-60) Use an external XML Pull parser instead of plexus one
[
https://issues.apache.org/jira/browse/DOXIA-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed DOXIA-60.
-
Resolution: Won't Do
> Use an external XML Pull parser instead of plexus one
> -
>
> Key: DOXIA-60
> URL: https://issues.apache.org/jira/browse/DOXIA-60
> Project: Maven Doxia
> Issue Type: Dependency upgrade
> Components: Core
>Reporter: Carlos Sanchez Gonzalez
>Priority: Major
> Labels: intern
>
> To avoid maintaining the plexus XMLPullParser we should move to a standard
> implementation like Codehaus StaX http://stax.codehaus.org
> {code:xml}
> stax
> stax
> 1.2.0_rc2-dev
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MINVOKER-366) Require Maven 3.6.3
[ https://issues.apache.org/jira/browse/MINVOKER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MINVOKER-366. Resolution: Fixed > Require Maven 3.6.3 > --- > > Key: MINVOKER-366 > URL: https://issues.apache.org/jira/browse/MINVOKER-366 > Project: Maven Invoker 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] [Commented] (MINVOKER-366) Require Maven 3.6.3
[ https://issues.apache.org/jira/browse/MINVOKER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844430#comment-17844430 ] ASF GitHub Bot commented on MINVOKER-366: - slawekjaranowski merged PR #238: URL: https://github.com/apache/maven-invoker-plugin/pull/238 > Require Maven 3.6.3 > --- > > Key: MINVOKER-366 > URL: https://issues.apache.org/jira/browse/MINVOKER-366 > Project: Maven Invoker 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)
Re: [PR] [MINVOKER-366] Require Maven 3.6.3 [maven-invoker-plugin]
slawekjaranowski merged PR #238: URL: https://github.com/apache/maven-invoker-plugin/pull/238 -- 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] (MSHARED-971) System environment variable are always added to maven-invoker
[
https://issues.apache.org/jira/browse/MSHARED-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MSHARED-971:
Fix Version/s: maven-invoker-3.3.0
> System environment variable are always added to maven-invoker
> -
>
> Key: MSHARED-971
> URL: https://issues.apache.org/jira/browse/MSHARED-971
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-invoker, maven-shared-utils
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Minor
> Fix For: maven-invoker-3.3.0
>
>
> In {{org.apache.maven.shared.invoker.MavenCommandLineBuilder}}
> [https://github.com/apache/maven-invoker/blob/d58703dd592ba0bc6f0a09928d0cce90e4002af9/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java#L197-L242]
> we have code:
> {code}
> if ( request.isShellEnvironmentInherited() )
> {
> cli.addSystemEnvironment();
> }
> {code}
> but in {{org.apache.maven.shared.utils.cli.Commandline}} we have:
> {code}
> public String[] getEnvironmentVariables()
> {
> addSystemEnvironment();
>...
> }
> {code}
> System environment variable are always added - it is inconsistent
> implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-971) System environment variable are always added to maven-invoker
[
https://issues.apache.org/jira/browse/MSHARED-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844428#comment-17844428
]
ASF GitHub Bot commented on MSHARED-971:
slawekjaranowski opened a new pull request, #79:
URL: https://github.com/apache/maven-invoker/pull/79
https://issues.apache.org/jira/browse/MSHARED-971
> System environment variable are always added to maven-invoker
> -
>
> Key: MSHARED-971
> URL: https://issues.apache.org/jira/browse/MSHARED-971
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-invoker, maven-shared-utils
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Minor
>
> In {{org.apache.maven.shared.invoker.MavenCommandLineBuilder}}
> [https://github.com/apache/maven-invoker/blob/d58703dd592ba0bc6f0a09928d0cce90e4002af9/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java#L197-L242]
> we have code:
> {code}
> if ( request.isShellEnvironmentInherited() )
> {
> cli.addSystemEnvironment();
> }
> {code}
> but in {{org.apache.maven.shared.utils.cli.Commandline}} we have:
> {code}
> public String[] getEnvironmentVariables()
> {
> addSystemEnvironment();
>...
> }
> {code}
> System environment variable are always added - it is inconsistent
> implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8118) Dependency-management "client" exclusions overwrite BOM exclusions
[ https://issues.apache.org/jira/browse/MNG-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-8118: Assignee: Guillaume Nodet > Dependency-management "client" exclusions overwrite BOM exclusions > -- > > Key: MNG-8118 > URL: https://issues.apache.org/jira/browse/MNG-8118 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-13, 4.0.x-candidate > Environment: Any >Reporter: Lenny Primak >Assignee: Guillaume Nodet >Priority: Major > > When importing BOM and introducing exclusions, they overwrite exclusions > already present in the BOM. They should not > Slack conversation link: > https://the-asf.slack.com/archives/C7Q9JB404/p1714938396499939 > Regressed by https://issues.apache.org/jira/browse/MNG-5600 > Reproducer app: [https://github.com/lprimak/apps/tree/main/emailmanager] > Fixed by: https://github.com/apache/maven/pull/1504 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-338) Upgrade to Parent 42
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844423#comment-17844423 ] ASF GitHub Bot commented on DOXIASITETOOLS-338: --- michael-o opened a new pull request, #153: URL: https://github.com/apache/maven-doxia-sitetools/pull/153 This closes #153 > Upgrade to Parent 42 > > > Key: DOXIASITETOOLS-338 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-338 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0, 2.0.0-M19 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-338) Upgrade to Parent 42
Michael Osipov created DOXIASITETOOLS-338: - Summary: Upgrade to Parent 42 Key: DOXIASITETOOLS-338 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-338 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.0.0, 2.0.0-M19 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1392) Upgrade to Parent 42
[ https://issues.apache.org/jira/browse/MSHARED-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844419#comment-17844419 ] Michael Osipov commented on MSHARED-1392: - Fixed with [b5b66f4c6e468685f5105e8d2a965f240b335f5f|https://gitbox.apache.org/repos/asf?p=maven-reporting-api.git;a=commit;h=b5b66f4c6e468685f5105e8d2a965f240b335f5f] for maven-reporting-api. > Upgrade to Parent 42 > > > Key: MSHARED-1392 > URL: https://issues.apache.org/jira/browse/MSHARED-1392 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-api, maven-reporting-exec, > maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-api-4.0.0, maven-reporting-impl-4.0.0, > maven-reporting-exec-2.0.0, maven-reporting-api-4.0.0-M12, > maven-reporting-impl-4.0.0-M15, maven-reporting-exec-2.0.0-M14 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8118) Dependency-management "client" exclusions overwrite BOM exclusions
Lenny Primak created MNG-8118: - Summary: Dependency-management "client" exclusions overwrite BOM exclusions Key: MNG-8118 URL: https://issues.apache.org/jira/browse/MNG-8118 Project: Maven Issue Type: Bug Affects Versions: 4.0.0-alpha-13, 4.0.x-candidate Environment: Any Reporter: Lenny Primak When importing BOM and introducing exclusions, they overwrite exclusions already present in the BOM. They should not Slack conversation link: https://the-asf.slack.com/archives/C7Q9JB404/p1714938396499939 Regressed by https://issues.apache.org/jira/browse/MNG-5600 Reproducer app: [https://github.com/lprimak/apps/tree/main/emailmanager] Fixed by: https://github.com/apache/maven/pull/1504 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Merge BOM exclusions instead of overwriting [maven]
lprimak commented on PR #1504: URL: https://github.com/apache/maven/pull/1504#issuecomment-2098839812 I believe that should do it! yes! -- 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] Merge BOM exclusions instead of overwriting [maven]
gnodet opened a new pull request, #1504: URL: https://github.com/apache/maven/pull/1504 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] 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. - [ ] 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
Re: [PR] Fix typo in maven-build-cache-config.xml [maven-build-cache-extension]
CrazyHZM merged PR #150: URL: https://github.com/apache/maven-build-cache-extension/pull/150 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump maven.plugin-tools.version from 3.12.0 to 3.13.0 [maven-mvnd]
CrazyHZM merged PR #987: URL: https://github.com/apache/maven-mvnd/pull/987 -- 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 io.takari.maven:takari-smart-builder from 0.6.5 to 0.6.6 [maven-mvnd]
CrazyHZM merged PR #986: URL: https://github.com/apache/maven-mvnd/pull/986 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-8117) Improve prerequisite evaluation and plugin version selection logging
[
https://issues.apache.org/jira/browse/MNG-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8117:
-
Description:
Currently, when user uses {{G:A}} the plugin tried is {{G:A:LATEST}} and is
checked for "compatibility" (Maven prerequisite in Maven3 and Maven4, plus for
Java prerequisite in Maven4 only). This may lead that "latest" (by Maven
Metadata) version is not compatible, and Maven will cycle toward older
versions. But the console output is a mess.
Current output can be seen in this gist:
[https://gist.github.com/cstamas/e44a2e51f5ec9f2e803dfb1d487d2fd5]
PR creates output like this:
https://gist.github.com/cstamas/3ca4bc6cea5f701054061871b5db3f35
was:Currently, when user uses {{G:A}} the plugin tried is {{G:A:LATEST}} and
is checked for "compatibility" (Maven prerequisite in Maven3 and Maven4, plus
for Java prerequisite in Maven4 only). This may lead that "latest" (by Maven
Metadata) version is not compatible, and Maven will cycle toward older
versions. But the console output is a mess.
> Improve prerequisite evaluation and plugin version selection logging
>
>
> Key: MNG-8117
> URL: https://issues.apache.org/jira/browse/MNG-8117
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-1
>
>
> Currently, when user uses {{G:A}} the plugin tried is {{G:A:LATEST}} and is
> checked for "compatibility" (Maven prerequisite in Maven3 and Maven4, plus
> for Java prerequisite in Maven4 only). This may lead that "latest" (by Maven
> Metadata) version is not compatible, and Maven will cycle toward older
> versions. But the console output is a mess.
> Current output can be seen in this gist:
> [https://gist.github.com/cstamas/e44a2e51f5ec9f2e803dfb1d487d2fd5]
> PR creates output like this:
> https://gist.github.com/cstamas/3ca4bc6cea5f701054061871b5db3f35
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGIN-523) Split Maven3 and Maven4 support
Tamas Cservenak created MPLUGIN-523: --- Summary: Split Maven3 and Maven4 support Key: MPLUGIN-523 URL: https://issues.apache.org/jira/browse/MPLUGIN-523 Project: Maven Plugin Tools Issue Type: Task Components: Plugin Plugin Reporter: Tamas Cservenak Fix For: 3.14.0 We should split m-p-p (two branches), one for Maven3 (maven-3.x) and one for Maven4 (master), as plugin can be only this or that, no need to support both at same time. This will result in simpl(er) code base, defaults, config. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MPLUGIN-522: Fix Version/s: 3.14.0 > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.14.0 > > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Add hint about mvnrepository.com [maven-site]
tamaro-skaljic commented on code in PR #518:
URL: https://github.com/apache/maven-site/pull/518#discussion_r1592339942
##
content/apt/guides/getting-started/index.apt:
##
@@ -910,7 +910,9 @@ mvn process-resources "-Dcommand.line.prop=hello again"
various plugins used to build the project). By default, the remote
repository Maven uses can be found (and browsed) at
{{https://repo.maven.apache.org/maven2/}}. You can also set up your own
remote repository (maybe a central repository for your company) to
use instead of or in addition to the default remote repository. For more
information on repositories you can refer to the
- {{{../introduction/introduction-to-repositories.html}Introduction to
Repositories}}.
+ {{{../introduction/introduction-to-repositories.html}Introduction to
Repositories}}. The best way to find information about dependencies is
Review Comment:
Done.
--
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 typo in maven-build-cache-config.xml [maven-build-cache-extension]
mfoo opened a new pull request, #150: URL: https://github.com/apache/maven-build-cache-extension/pull/150 Hi all! This is a one character typo fix in the site docs. I have read the PR template but I have not created a ticket in the [MBUILDCACHE](https://issues.apache.org/jira/browse/MBUILDCACHE) project. I note that the banner at the top says: > Public signup for this instance is disabled. Go to our [Self serve sign up page](https://selfserve.apache.org/jira-account.html) to request an account. Unfortunately I currently don't have time to follow this process, and I [couldn't find](https://issues.apache.org/jira/issues/?jql=project%20%3D%20MBUILDCACHE%20AND%20summary%20~%20%22typo%22) other typo tickets, so I was hoping it wouldn't be needed for such a small change. I also have also not signed an individual contributor agreement due to the size of the change. Please let me know if these are problems. ## License acknowledgement 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) -- 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] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844221#comment-17844221 ] ASF GitHub Bot commented on MPLUGIN-522: cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097841309 But just for the record: current m-p-p releases produce broken Maven Plugin XML, in a way that plugin works just fine with Maven3, while Maven4 explodes with invalid error messages. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-522] Prerequisites should be opt-in [maven-plugin-tools]
cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097841309 But just for the record: current m-p-p releases produce broken Maven Plugin XML, in a way that plugin works just fine with Maven3, while Maven4 explodes with invalid error messages. -- 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] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844220#comment-17844220 ] ASF GitHub Bot commented on MPLUGIN-522: cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097838429 This PR should be redone once Maven3 and Maven4 m-p-p are split (into maven-3.x and master) branch. And then: * default Java prerequisite should pick up from compiler plugin (in pretty much similar way as report does) * default Maven prerequisite should be "3.2.5" on maven-3.x branch and "4.0.0" on master branch. Originally, the lack of prerequisite meant "it works with Maven3" (no range specified). IMO, using "3.2.5" today is completely okay, it covers 10 years of history. If users wants to go more backward, it can explicitly configure prerequisite to "3.1.1" or whatever. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-522] Prerequisites should be opt-in [maven-plugin-tools]
cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097838429 This PR should be redone once Maven3 and Maven4 m-p-p are split (into maven-3.x and master) branch. And then: * default Java prerequisite should pick up from compiler plugin (in pretty much similar way as report does) * default Maven prerequisite should be "3.2.5" on maven-3.x branch and "4.0.0" on master branch. Originally, the lack of prerequisite meant "it works with Maven3" (no range specified). IMO, using "3.2.5" today is completely okay, it covers 10 years of history. If users wants to go more backward, it can explicitly configure prerequisite to "3.1.1" or whatever. -- 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] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844218#comment-17844218 ] ASF GitHub Bot commented on MPLUGIN-522: cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097814145 > I think enforcing and explicitly stating prerequisites is a good thing and the default matches for 99% of the cases. For other cases just overwrite with explicit values. Not stating prerequisites should no longer be supported because it is frustratring for users to figure out the implicit prerequisites through trial and error... Just to repeat myself, the prerequisites are documented, so no need for user trial-and-error. This table shows Maven and Java prerequisites clearly: https://maven.apache.org/plugins/maven-jar-plugin/plugin-info.html#system-requirements-history > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-522] Prerequisites should be opt-in [maven-plugin-tools]
cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097814145 > I think enforcing and explicitly stating prerequisites is a good thing and the default matches for 99% of the cases. For other cases just overwrite with explicit values. Not stating prerequisites should no longer be supported because it is frustratring for users to figure out the implicit prerequisites through trial and error... Just to repeat myself, the prerequisites are documented, so no need for user trial-and-error. This table shows Maven and Java prerequisites clearly: https://maven.apache.org/plugins/maven-jar-plugin/plugin-info.html#system-requirements-history -- 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] [MPLUGIN-522] Prerequisites should be opt-in [maven-plugin-tools]
kwin commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097722820 > Putting prerequisites which are greater than the one actually used to build are, at first, very weird. Let's focus on issue with the automatic detection. Please point me to a concrete example where this is the case and where it is 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] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844200#comment-17844200 ] ASF GitHub Bot commented on MPLUGIN-522: kwin commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097722820 > Putting prerequisites which are greater than the one actually used to build are, at first, very weird. Let's focus on issue with the automatic detection. Please point me to a concrete example where this is the case and where it is wrong. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844199#comment-17844199 ] ASF GitHub Bot commented on MPLUGIN-522: cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097721382 Also, unsure how then this thing works? https://maven.apache.org/plugins/maven-jar-plugin/plugin-info.html#system-requirements-history > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-522] Prerequisites should be opt-in [maven-plugin-tools]
cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097721382 Also, unsure how then this thing works? https://maven.apache.org/plugins/maven-jar-plugin/plugin-info.html#system-requirements-history -- 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] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:18 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? ... Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. Similarly, if I have one class that is Java 22, the plugin prerequisite is NOT Java 22. It the class is in the plugin classpath I would assume that this is necessary for plugin execution (not necessarily for each mojo). If the class isn't being called then it shouldn't be there in the first place... bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. was (Author: kwin): bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844198#comment-17844198 ] ASF GitHub Bot commented on MPLUGIN-522: gnodet commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097717570 > I think enforcing prerequisites is a good thing and the default match for 99% of the cases. For other cases just overwrite with explicit values. Not stating prerequisites should no longer be supported because it is frustratring for users to figure out the implicit prerequisites through trial and error... Putting prerequisites which are greater than the one actually used to build are, at first, very weird. For example, if you project requires jdk 11, you build with jdk 11, test it with jdk 11, but your prerequisites ends up with jdk 22... ? That's really unexpected, and the user has no real knowledge about the value used. The prerequisites should not be higher than the target JDK. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844197#comment-17844197 ] ASF GitHub Bot commented on MPLUGIN-522: cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097716799 Ok, then we have similar situation as with prefix: fail the build. Plugin should be modified to: * if none set, fail the build * if "auto", as now * if value set, use that We must make users aware of this requirement (hence the build failure), as otherwise they implicitly use "auto" and end result is wrong. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-522] Prerequisites should be opt-in [maven-plugin-tools]
gnodet commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097717570 > I think enforcing prerequisites is a good thing and the default match for 99% of the cases. For other cases just overwrite with explicit values. Not stating prerequisites should no longer be supported because it is frustratring for users to figure out the implicit prerequisites through trial and error... Putting prerequisites which are greater than the one actually used to build are, at first, very weird. For example, if you project requires jdk 11, you build with jdk 11, test it with jdk 11, but your prerequisites ends up with jdk 22... ? That's really unexpected, and the user has no real knowledge about the value used. The prerequisites should not be higher than the target JDK. -- 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] [MPLUGIN-522] Prerequisites should be opt-in [maven-plugin-tools]
cstamas commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097716799 Ok, then we have similar situation as with prefix: fail the build. Plugin should be modified to: * if none set, fail the build * if "auto", as now * if value set, use that We must make users aware of this requirement (hence the build failure), as otherwise they implicitly use "auto" and end result is 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] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844195#comment-17844195 ] Tamas Cservenak commented on MPLUGIN-522: - Also, your statement is wrong: toolbox plugin does NOT have Java 22 "in plugin". It has it in among dependencies, not the same (and is not even user-controlled). > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844195#comment-17844195 ] Tamas Cservenak edited comment on MPLUGIN-522 at 5/7/24 8:14 AM: - Also, your statement is wrong: toolbox plugin does NOT have Java 22 class "in plugin". It has it in among dependencies, not the same (and is not even user-controlled). was (Author: cstamas): Also, your statement is wrong: toolbox plugin does NOT have Java 22 "in plugin". It has it in among dependencies, not the same (and is not even user-controlled). > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844192#comment-17844192 ] Tamas Cservenak commented on MPLUGIN-522: - Currently m-p-p produces plugins: * that happily works on Java 11 w/ Maven 3.6.3 * but fails with Maven 4 (that observe these new entries in plugin descriptor) due fals prerequisites: it claims it needs Java 22 and Maven 3.9.6, and none of these are true I, as a developer was totally oblivious of these auto-set values, until i tried the plugin with Maven4. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844189#comment-17844189 ] Tamas Cservenak commented on MPLUGIN-522: - In that case just fail the build (like we did with prefix). You cannot auto deduce developer intent, as example shows, it happens in a wrong way. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:10 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. was (Author: kwin): bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844188#comment-17844188 ] Konrad Windszus commented on MPLUGIN-522: - > why it gets "highest class version present on classpath"? Why not compiler > target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. > if I compile against 3.9.6 Maven APIs, that – due backward compatibility – > does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are > happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:08 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. was (Author: kwin): > why it gets "highest class version present on classpath"? Why not compiler > target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. > if I compile against 3.9.6 Maven APIs, that – due backward compatibility – > does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are > happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[
https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17843885#comment-17843885
]
Tamas Cservenak edited comment on MPLUGIN-522 at 5/7/24 8:07 AM:
-
Example: try with Maven4 + Java 21: {{mvn
eu.maveniverse.maven.plugins:toolbox:tree}} and it will explode, claiming
"plugin requires Java 22". Now use Java 11 and Maven 3.6.3, and plugin works!
was (Author: cstamas):
Example: try with Maven4 + Java 21: {{mvn
eu.maveniverse.maven.plugins:toolbox:tree}} and it will explode, claiming
"plugin requires Java 22". Now use Java 11 and Maven 3.9.6, and plugin works!
> The auto prerequisites are way to aggressive
>
>
> Key: MPLUGIN-522
> URL: https://issues.apache.org/jira/browse/MPLUGIN-522
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Reporter: Tamas Cservenak
>Priority: Major
>
> IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong.
> They are way too aggresive and violate backward compatibility: if new feature
> is not explicitly set by user, code should not "come up" with some automatic
> value. By having the value not set simply means user does not want to use it.
> This is especially true for (maven or java) prerequisite, as it creates HARD
> BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto
> user.
> [~kwin]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844186#comment-17844186 ] ASF GitHub Bot commented on MPLUGIN-522: kwin commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097692140 > and in fact, plain wrong. I disagree with this statement, and also disagree that they should be opt in. Details in the JIRA. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-522] Prerequisites should be opt-in [maven-plugin-tools]
kwin commented on PR #282: URL: https://github.com/apache/maven-plugin-tools/pull/282#issuecomment-2097692140 > and in fact, plain wrong. I disagree with this statement, and also disagree that they should be opt in. Details in the JIRA. -- 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] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844184#comment-17844184 ] Tamas Cservenak commented on MPLUGIN-522: - For example the java prerequisite: why it gets "highest class version present on classpath"? Why not compiler target instead? For Maven prerequisite: you cannot infer Maven prerequisite based on API you compile against. As mentioned, even if I compile against latest (3.9.6), the plugin may just fine work with 3.6.3 as well. Hence, these two should be and remain (as before) opt in values. We cannot "deduce" what user wants, it is up to user to tell us what he wants. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844181#comment-17844181 ] ASF GitHub Bot commented on MPLUGIN-522: cstamas opened a new pull request, #282: URL: https://github.com/apache/maven-plugin-tools/pull/282 But they are not. In fact, if user does not deal with them, they are way too aggressive and in fact, plain wrong. Prerequisite was opt-in and should have remain opt-in. --- https://issues.apache.org/jira/browse/MPLUGIN-522 > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump version.maven-plugin-tools from 3.12.0 to 3.13.0 [maven-apache-parent]
slawekjaranowski commented on PR #223: URL: https://github.com/apache/maven-apache-parent/pull/223#issuecomment-2097659452 https://github.com/apache/maven-plugin-tools/releases/tag/maven-plugin-tools-3.13.0 -- 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
