[jira] [Commented] (MPLUGIN-510) update plugin system requirements history structure
[ https://issues.apache.org/jira/browse/MPLUGIN-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820583#comment-17820583 ] ASF GitHub Bot commented on MPLUGIN-510: hboutemy closed pull request #263: [MPLUGIN-510] move requirement detection code URL: https://github.com/apache/maven-plugin-tools/pull/263 > update plugin system requirements history structure > --- > > Key: MPLUGIN-510 > URL: https://issues.apache.org/jira/browse/MPLUGIN-510 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > in MPLUGIN-400, we added the feature with a list of versions of the plugin, > associated to Maven and JDK prerequisite > https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories > => started to use for example: > [https://maven.apache.org/plugins-archives/maven-assembly-plugin-3.6.0/plugin-info.html] > this lead to questions: should we fill each and every past version? Or should > we group by common prerequisites, showing only ranges? > Tested the range approach: > [https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/plugin-info.html] > the range approach looks good: minimum lines (vs listing every version), > clear choice for users (choose the latest in the range, or pick any > intermediate one) > now, we need to rework the m-p-p configuration to replace "version" with > "from" + "to", instead of hijacking the "version" field to store a String > "from x to y" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-511) create and share tooling to detect plugin prerequsites history
[ https://issues.apache.org/jira/browse/MPLUGIN-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820582#comment-17820582 ] ASF GitHub Bot commented on MPLUGIN-511: hboutemy opened a new pull request, #264: URL: https://github.com/apache/maven-plugin-tools/pull/264 (no comment) > create and share tooling to detect plugin prerequsites history > -- > > Key: MPLUGIN-511 > URL: https://issues.apache.org/jira/browse/MPLUGIN-511 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > to help creating documentation needed on plugins when implementing > MPLUGIN-400, i.e. fill requirementsHistories > [https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories] > > this will be useful both for Maven project itself, because we have 52 plugins > to work on > [https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html] > but this will help also every plugin maintainers: MojoHaus, others -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-510] move requirement detection code [maven-plugin-tools]
hboutemy closed pull request #263: [MPLUGIN-510] move requirement detection code URL: https://github.com/apache/maven-plugin-tools/pull/263 -- 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] [MPLUGIN-511] move requirement detection code [maven-plugin-tools]
hboutemy opened a new pull request, #264: URL: https://github.com/apache/maven-plugin-tools/pull/264 (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] [Updated] (MARTIFACT-58) display origin of local repository artifact when comparing
[ https://issues.apache.org/jira/browse/MARTIFACT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MARTIFACT-58: --- Labels: (was: up-for-grabs) > display origin of local repository artifact when comparing > -- > > Key: MARTIFACT-58 > URL: https://issues.apache.org/jira/browse/MARTIFACT-58 > Project: Maven Artifact Plugin > Issue Type: Wish > Components: artifact:compare >Affects Versions: 3.5.0 >Reporter: Herve Boutemy >Priority: Major > > artifact:compare compares output from current build (available in target/) to > content from local repository > what is not easy to detect is if content from local repository comes from a > previous local "mvn install" (done recently or a long time ago) or if it was > downloaded from a remote repository > perhaps the artifact:compare can detect and display the info -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-510) update plugin system requirements history structure
[ https://issues.apache.org/jira/browse/MPLUGIN-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820555#comment-17820555 ] ASF GitHub Bot commented on MPLUGIN-510: hboutemy opened a new pull request, #263: URL: https://github.com/apache/maven-plugin-tools/pull/263 (no comment) > update plugin system requirements history structure > --- > > Key: MPLUGIN-510 > URL: https://issues.apache.org/jira/browse/MPLUGIN-510 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > in MPLUGIN-400, we added the feature with a list of versions of the plugin, > associated to Maven and JDK prerequisite > https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories > => started to use for example: > [https://maven.apache.org/plugins-archives/maven-assembly-plugin-3.6.0/plugin-info.html] > this lead to questions: should we fill each and every past version? Or should > we group by common prerequisites, showing only ranges? > Tested the range approach: > [https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/plugin-info.html] > the range approach looks good: minimum lines (vs listing every version), > clear choice for users (choose the latest in the range, or pick any > intermediate one) > now, we need to rework the m-p-p configuration to replace "version" with > "from" + "to", instead of hijacking the "version" field to store a String > "from x to y" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MPLUGIN-510] move requirement detection code [maven-plugin-tools]
hboutemy opened a new pull request, #263: URL: https://github.com/apache/maven-plugin-tools/pull/263 (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.bcel:bcel from 6.7.0 to 6.8.2 [maven-shared-jar]
dependabot[bot] opened a new pull request, #35: URL: https://github.com/apache/maven-shared-jar/pull/35 Bumps [org.apache.bcel:bcel](https://github.com/apache/commons-bcel) from 6.7.0 to 6.8.2. Changelog Sourced from https://github.com/apache/commons-bcel/blob/master/RELEASE-NOTES.txt;>org.apache.bcel:bcel's changelog. Apache Commons BCEL Version 6.8.2 RELEASE NOTES Introduction The Apache Commons BCEL team is pleased to announce the release of Apache Commons BCEL 6.8.2. The Byte Code Engineering Library (BCEL) is intended to give users a convenient way to analyze, create, and manipulate compiled .class files. Classes are represented by objects containing all the symbolic information of the given class: methods, fields, and byte code instructions. Maintenance and bug fix release. New Features Fix ConcurrentModificationException in org.apache.bcel.util.SyntheticRepository.getInstance() [#275](https://github.com/apache/commons-bcel/issues/275). Thanks to Guillaume Nodet. Add Maven property project.build.outputTimestamp for build reproducibility. Thanks to Gary Gregory. Changes Bump GitHub various actions for CI builds. Thanks to Dependabot. Bump org.assertj:assertj-core from 3.25.1 to 3.25.2. Thanks to Dependabot. Bump org.apache.commons:commons-parent from 65 to 66. Thanks to Dependabot. Historical list of changes: https://commons.apache.org/proper/commons-bcelchanges-report.html;>https://commons.apache.org/proper/commons-bcelchanges-report.html For complete information on Apache Commons BCEL, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons BCEL website: https://commons.apache.org/proper/commons-bcel;>https://commons.apache.org/proper/commons-bcel Download it from https://commons.apache.org/proper/commons-bcel/download_bcel.cgi;>https://commons.apache.org/proper/commons-bcel/download_bcel.cgi Have fun! -Apache Commons BCEL team Feedback Open source works best when you give feedback: https://commons.apache.org/bcel Please direct all bug reports to JIRA: https://issues.apache.org/jira/browse/BCEL ... (truncated) Commits https://github.com/apache/commons-bcel/commit/749d99c14180afb991dca2d02c1ad75fd97f417f;>749d99c Prepare release candidate https://github.com/apache/commons-bcel/commit/e7cfca276d25bffac017f47a215d01cbcba2f898;>e7cfca2 Prepare release candidate https://github.com/apache/commons-bcel/commit/d6e29d1f11ef154eb89da9346db8993f366eb31f;>d6e29d1 Whitespace https://github.com/apache/commons-bcel/commit/51254ed5ec044681d2936cc39535af474c8a8929;>51254ed Fix ConcurrentModificationException in org.apache.bcel.util.SyntheticReposito... https://github.com/apache/commons-bcel/commit/767ea9f458c26de469fdbc88024a54bc388ac90a;>767ea9f Fix concurrent map access exception (https://redirect.github.com/apache/commons-bcel/issues/275;>#275) https://github.com/apache/commons-bcel/commit/01fd7ec296bf057ccde3802e5aebbc9528aa1b74;>01fd7ec Bump github/codeql-action from 3.24.0 to 3.24.3 (https://redirect.github.com/apache/commons-bcel/issues/274;>#274) https://github.com/apache/commons-bcel/commit/e144e4c73072118ad1bd6425f3c2c69c1cf1a634;>e144e4c Bump actions/upload-artifact from 4.3.0 to 4.3.1 (https://redirect.github.com/apache/commons-bcel/issues/273;>#273) https://github.com/apache/commons-bcel/commit/ca9d55dd498115a86fde8a0ebb270e3c8a4fc1cc;>ca9d55d Bump org.assertj:assertj-core from 3.25.2 to 3.25.3 (https://redirect.github.com/apache/commons-bcel/issues/272;>#272) https://github.com/apache/commons-bcel/commit/b381bea09590fc8485b05edbe50c02edaf978020;>b381bea Use StringBuilder https://github.com/apache/commons-bcel/commit/e1e5f5ed551dc4c509009b4847ed1f5dc43ec9a0;>e1e5f5e Remove variable assignment just before returning it Additional commits viewable in https://github.com/apache/commons-bcel/compare/rel/commons-bcel-6.7.0...rel/commons-bcel-6.8.2;>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,
[PR] Bump org.gaul:modernizer-maven-plugin from 2.7.0 to 2.8.0 [maven-indexer]
dependabot[bot] opened a new pull request, #354: URL: https://github.com/apache/maven-indexer/pull/354 Bumps [org.gaul:modernizer-maven-plugin](https://github.com/gaul/modernizer-maven-plugin) from 2.7.0 to 2.8.0. Release notes Sourced from https://github.com/gaul/modernizer-maven-plugin/releases;>org.gaul:modernizer-maven-plugin's releases. Modernizer Maven Plugin 2.8.0 Add m2e hint, https://redirect.github.com/gaul/modernizer-maven-plugin/issues/213;>#213 Add support for different output formats and add codeclimate as an output format, https://redirect.github.com/gaul/modernizer-maven-plugin/issues/235;>#235 Upgrade to ASM 9.6, https://redirect.github.com/gaul/modernizer-maven-plugin/issues/222;>#222 Thanks https://github.com/hazendaz;>@hazendaz and https://github.com/themadprofessor;>@themadprofessor for sending pull requests to improve Modernizer! Commits https://github.com/gaul/modernizer-maven-plugin/commit/fe0509f227162c31c7a3697da15339c5ef98b84d;>fe0509f Upgrade to nexus-staging-maven-plugin 1.6.13 https://github.com/gaul/modernizer-maven-plugin/commit/95dc6409f106009bc928d0399b441fb7f113a287;>95dc640 modernizer-maven-plugin 2.8.0 release https://github.com/gaul/modernizer-maven-plugin/commit/557a6ef712cef4044b06f1ca1733f7215c1f700f;>557a6ef Bump java.version to 1.7 to match main pom.xml https://github.com/gaul/modernizer-maven-plugin/commit/5f9824a678e8bd70deb7c1dfeaf1baa551385c02;>5f9824a Bump mavenVersion from 3.8.1 to 3.9.5 https://github.com/gaul/modernizer-maven-plugin/commit/f168539ca1ce6b713fcdeaf5fe5828adae824609;>f168539 Bump org.apache.maven.plugins:maven-plugin-plugin from 3.6.0 to 3.11.0 https://github.com/gaul/modernizer-maven-plugin/commit/641fed6b6158c321be4297cd776392a8f43625bd;>641fed6 Add support for different output formats and add codeclimate as an output format https://github.com/gaul/modernizer-maven-plugin/commit/2b56d876ff8e6bdca87ed70aba0ae11323a6ee28;>2b56d87 Bump org.assertj:assertj-core from 1.7.1 to 3.25.2 https://github.com/gaul/modernizer-maven-plugin/commit/3d51178dccf13aa0c3a38c37a6af92ee56001689;>3d51178 Bump org.springframework:spring-beans in /modernizer-maven-plugin https://github.com/gaul/modernizer-maven-plugin/commit/eecc862fe7b47ca7c12bf2cd2a70566a650a1cf7;>eecc862 Bump com.google.inject:guice from 4.0 to 7.0.0 https://github.com/gaul/modernizer-maven-plugin/commit/36aaa7c9700d29609f32bfa2cc296af24669231d;>36aaa7c Bump commons-io:commons-io from 2.13.0 to 2.15.1 Additional commits viewable in https://github.com/gaul/modernizer-maven-plugin/compare/modernizer-maven-plugin-2.7.0...modernizer-maven-plugin-2.8.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:
Re: [PR] Automatic discovery of JDK toolchains [maven-toolchains-plugin]
norrisjeremy commented on PR #14:
URL:
https://github.com/apache/maven-toolchains-plugin/pull/14#issuecomment-1963061427
> > Wouldn't it be great if `settings.xml` could also be made optional by
usage of env vars as well?
>
> Settings are already interpolated so we can use env vars already, I'm
using it locally with the following:
>
> ```
>
> central
> central
> ${env.MAVEN_CENTRAL}
>
> ```
>
> so that I can point to a mirror on my LAN when available.
>
> Toolchains are also interpolated and env vars seems to be supported too
fwiw.
>
> So it's not really settings being optional, but it's easy to setup a
project's settings.xml or toolchains.xml that just use env variables, wouldn't
that work ?
The point is to have a standard method by which Maven can detect specific
env vars for this without having to explicitly write a `settings.xml` or
`toolchains.xml`, as it is an inconvenience to both generate and maintain these
files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MSHARED-1359) Allow reuse the same classloader for multiple scrip executions
[
https://issues.apache.org/jira/browse/MSHARED-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MSHARED-1359:
-
Description:
We can pass a {{context}} to script, so script can create an object and store
it in {{{}context{}}}.
Next executing of script can not use object from {{context}} due to new
{{classloader}} in next execution.
was:
We can pass a {{context}} to script, so script can create an object and store
it in context.
Next executing script can use object due to new {{classloader}} in next
execution.
> Allow reuse the same classloader for multiple scrip executions
> --
>
> Key: MSHARED-1359
> URL: https://issues.apache.org/jira/browse/MSHARED-1359
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-script-interpreter
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-script-interpreter-1.5
>
>
> We can pass a {{context}} to script, so script can create an object and store
> it in {{{}context{}}}.
> Next executing of script can not use object from {{context}} due to new
> {{classloader}} in next execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1359) Allow reuse the same classloader for multiple scrip executions
Slawomir Jaranowski created MSHARED-1359:
Summary: Allow reuse the same classloader for multiple scrip
executions
Key: MSHARED-1359
URL: https://issues.apache.org/jira/browse/MSHARED-1359
Project: Maven Shared Components
Issue Type: New Feature
Components: maven-script-interpreter
Reporter: Slawomir Jaranowski
Fix For: maven-script-interpreter-1.5
We can pass a {{context}} to script, so script can create an object and store
it in context.
Next executing script can use object due to new {{classloader}} in next
execution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-577) Rename parameter "forceJavacCompilerUse"
[
https://issues.apache.org/jira/browse/MCOMPILER-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MCOMPILER-577:
--
Description:
The name {{forceJavacCompilerUse}}
(https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#forceJavacCompilerUse)
is confusing, because it only determines which API to use to access {{javac}},
but doesn't actually affect the compiler being used (which is determined via
{{compilerId}} or toolchains).
I would propose to rename that to {{forceLegacyJavacApi}} and clarify that this
currently only has an effect on compiler {{javac}} (in case it is not forked).
In order to be backwards-compatible the old name should still be considered as
alias.
was:
The name {{forceJavacCompilerUse}}
(https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#forceJavacCompilerUse)
is confusing, because it only determines which API to use to access {{javac}},
but doesn't actually affect the compiler being used (which is determined via
{{compilerId}} or toolchains).
I would propose to rename that to {{forceLegacyJavacApi}} and clarify that this
currently only has an effect on compiler {{javac}}. In order to be
backwards-compatible the old name should still be considered as alias.
> Rename parameter "forceJavacCompilerUse"
>
>
> Key: MCOMPILER-577
> URL: https://issues.apache.org/jira/browse/MCOMPILER-577
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> The name {{forceJavacCompilerUse}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#forceJavacCompilerUse)
> is confusing, because it only determines which API to use to access
> {{javac}}, but doesn't actually affect the compiler being used (which is
> determined via {{compilerId}} or toolchains).
> I would propose to rename that to {{forceLegacyJavacApi}} and clarify that
> this currently only has an effect on compiler {{javac}} (in case it is not
> forked). In order to be backwards-compatible the old name should still be
> considered as alias.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-577) Rename parameter "forceJavacCompilerUse"
[
https://issues.apache.org/jira/browse/MCOMPILER-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MCOMPILER-577:
--
Description:
The name {{forceJavacCompilerUse}}
(https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#forceJavacCompilerUse)
is confusing, because it only determines which API to use to access {{javac}},
but doesn't actually affect the compiler being used (which is determined via
{{compilerId}} or toolchains).
I would propose to rename that to {{forceLegacyJavacApi}} and clarify that this
currently only has an effect on compiler {{javac}}. In order to be
backwards-compatible the old name should still be considered as alias.
was:
The name {{forceJavacCompilerUse}} is confusing, because it only determines
which API to use to access {{javac}}, but doesn't actually affect the compiler
being used (which is determined via {{compilerId}} or toolchains).
I would propose to rename that to {{forceLegacyJavacApi}} and clarify that this
currently only has an effect on compiler {{javac}}. In order to be
backwards-compatible the old name should still be considered as alias.
> Rename parameter "forceJavacCompilerUse"
>
>
> Key: MCOMPILER-577
> URL: https://issues.apache.org/jira/browse/MCOMPILER-577
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> The name {{forceJavacCompilerUse}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#forceJavacCompilerUse)
> is confusing, because it only determines which API to use to access
> {{javac}}, but doesn't actually affect the compiler being used (which is
> determined via {{compilerId}} or toolchains).
> I would propose to rename that to {{forceLegacyJavacApi}} and clarify that
> this currently only has an effect on compiler {{javac}}. In order to be
> backwards-compatible the old name should still be considered as alias.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCOMPILER-577) Rename parameter "forceJavacCompilerUse"
Konrad Windszus created MCOMPILER-577:
-
Summary: Rename parameter "forceJavacCompilerUse"
Key: MCOMPILER-577
URL: https://issues.apache.org/jira/browse/MCOMPILER-577
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: Konrad Windszus
Fix For: next-release
The name {{forceJavacCompilerUse}} is confusing, because it only determines
which API to use to access {{javac}}, but doesn't actually affect the compiler
being used (which is determined via {{compilerId}} or toolchains).
I would propose to rename that to {{forceLegacyJavacApi}} and clarify that this
currently only has an effect on compiler {{javac}}. In order to be
backwards-compatible the old name should still be considered as alias.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Automatic discovery of JDK toolchains [maven-toolchains-plugin]
rmannibucau commented on PR #14: URL: https://github.com/apache/maven-toolchains-plugin/pull/14#issuecomment-1963031413 > are already interpolated Yes this is what makes it complicated compared to not using it. The main issue is that it is never maintained - env var are cause it is the only thing being updated and widely used. So after some time you get a lot of pointless entries or entries pointing to path or env var not existing. Indeed we can add yet another mojo to detect that, and another one to try to fix it but a working solution without any code sounds more seducing to me than a hard to use one with a lot of processes and code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Edit and update [maven-site]
slawekjaranowski commented on PR #494: URL: https://github.com/apache/maven-site/pull/494#issuecomment-1963021223 Similar in plugin docs https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk.html Maybe we should drop a similar site from plugin documentations and have only one here ... -- 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] Edit and update [maven-site]
slawekjaranowski commented on PR #494: URL: https://github.com/apache/maven-site/pull/494#issuecomment-1963020538 We should also update plugins version used in examples ... we can use properties from parent like in: https://github.com/apache/maven-site/commit/6d4a7bc25dcb491600ac3821481018d2be371003 -- 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] (MNG-7864) Fix the S390x to use IT branches
[ https://issues.apache.org/jira/browse/MNG-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MNG-7864. Resolution: Fixed Fixed in https://github.com/apache/maven/pull/1313 > Fix the S390x to use IT branches > > > Key: MNG-7864 > URL: https://issues.apache.org/jira/browse/MNG-7864 > Project: Maven > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Slawomir Jaranowski >Priority: Major > > When testing a PR, the maven-integration-testing branch with the same name > should be used instead of master if it exists. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[ https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820501#comment-17820501 ] ASF GitHub Bot commented on MSHARED-1351: - abelsromero commented on PR #93: URL: https://github.com/apache/maven-filtering/pull/93#issuecomment-1963010320 > recently I've fixed similar code here [codehaus-plexus/plexus-compiler#364](https://github.com/codehaus-plexus/plexus-compiler/issues/364) Not sure is the same thing. I don't have context on the other project, but the issue is that `relativize` will return an empty string in some cases, not an exception. Seems to me that the issue could still happen in `plexus-compiler` . > Confusing message when copying resources from project's baseDir > --- > > Key: MSHARED-1351 > URL: https://issues.apache.org/jira/browse/MSHARED-1351 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-3.3.1 >Reporter: Abel Salgado Romero >Priority: Minor > Fix For: maven-filtering-3.3.2 > > > When the project base dir is used as the origin path, the relativize in > https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259 > resolves to empty string, resulting in nothing being displayed path after > "from" in the console: > ``` > Copying 118 resources from to target/generated-docs > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
abelsromero commented on PR #93: URL: https://github.com/apache/maven-filtering/pull/93#issuecomment-1963010320 > recently I've fixed similar code here [codehaus-plexus/plexus-compiler#364](https://github.com/codehaus-plexus/plexus-compiler/issues/364) Not sure is the same thing. I don't have context on the other project, but the issue is that `relativize` will return an empty string in some cases, not an exception. Seems to me that the issue could still happen in `plexus-compiler` . -- 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] Rewrite JDK toolchain docs [maven-toolchains-plugin]
slawekjaranowski commented on PR #18: URL: https://github.com/apache/maven-toolchains-plugin/pull/18#issuecomment-1963009823 We need parent at version 41 -- 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] Automatic discovery of JDK toolchains [maven-toolchains-plugin]
gnodet commented on PR #14:
URL:
https://github.com/apache/maven-toolchains-plugin/pull/14#issuecomment-1963004701
> > Cant we make toolchain.xml physically optional and replaced by some env
var naming convention instead? This way these new mojos are not needed and
therefore no need to maintain the generated value which is a challenge to
maintain until you make toolchain.xml an useless indirection using vars from my
XP. Sounds more natural to integrate with specific setups and CI and requires
less effort for us IMHO.
>
> Wouldn't it be great if `settings.xml` could also be made optional by
usage of env vars as well?
Settings are already interpolated so we can use env vars already, I'm using
it locally with the following:
```
central
central
${env.MAVEN_CENTRAL}
```
so that I can point to a mirror on my LAN when available.
Toolchains are also interpolated and env vars seems to be supported too fwiw.
--
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] (MTOOLCHAINS-48) Document how conflicting toolchains are resolved
Elliotte Rusty Harold created MTOOLCHAINS-48: Summary: Document how conflicting toolchains are resolved Key: MTOOLCHAINS-48 URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-48 Project: Maven Toolchains Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold That is, what happens if more than one toolchain matches? E.g. there are two configs for jdk with version 17, one for oracle and one for temurin, but the user only specified version 17. Which jdk do they get? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MTOOLCHAINS-44) Use default JDK if it matches the request and no other toolchain is defined
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820485#comment-17820485
]
Elliotte Rusty Harold commented on MTOOLCHAINS-44:
--
My gut is that if a toolchain can't be located, we shouldn't simply use
JAVA_HOME. Erroring is better here.
However, we might be able to define some defaults for certain JDK toolchains.
The common case for toolchains is that the user wants a specific JDK version.
If that's all they request, and toolchains.xml can't be found, or doesn't
contain a matching JDK version, maven could still search in standard locations
locally. For instance, suppose this is the configuration
{{
1.8
}}
On a Mac you could run "/usr/libexec/java_home -V" to find a JDK that provides
version 1.8.
> Use default JDK if it matches the request and no other toolchain is defined
> ---
>
> Key: MTOOLCHAINS-44
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-44
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: dennis lucero
>Priority: Major
>
> Currently it is needed to have the toolchains defined in the toolchains.xml
> file. The [Maven Docker images|https://hub.docker.com/_/maven] do not
> [include a useful toolchains
> file|https://github.com/carlossg/docker-maven/issues/303]. But since it’s
> possible to [derive a usable toolchain from the system
> properties|https://github.com/carlossg/docker-maven/issues/303#issuecomment-1310895631],
> it should not be required to store that information in the toolchains.xml
> file. Instead, Maven should check if the toolchain request could be fulfilled
> by the JDK running Maven.
> I’m not sure if it’s reasonable to do this in all cases or only if the
> toolchains file does not contain any toolchain. For example, if the
> toolchains file only contains a Java 16 toolchain and the project requires
> Java 17 (exactly, not 17 or later) and Maven is run with Java 17, it would be
> possible to build the project (with Java 17), but probably not a good idea
> since it will fail when the Java installation Maven is running on is updated
> to version 18.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Automatic discovery of JDK toolchains [maven-toolchains-plugin]
rmannibucau commented on PR #14: URL: https://github.com/apache/maven-toolchains-plugin/pull/14#issuecomment-1962957052 @norrisjeremy sure but not on this pr I guess ;) -- 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] Automatic discovery of JDK toolchains [maven-toolchains-plugin]
norrisjeremy commented on PR #14: URL: https://github.com/apache/maven-toolchains-plugin/pull/14#issuecomment-1962956171 > Cant we make toolchain.xml physically optional and replaced by some env var naming convention instead? This way these new mojos are not needed and therefore no need to maintain the generated value which is a challenge to maintain until you make toolchain.xml an useless indirection using vars from my XP. Sounds more natural to integrate with specific setups and CI and requires less effort for us IMHO. Wouldn't it be great if `settings.xml` could also be made optional by usage of env vars 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
Re: [PR] Automatic discovery of JDK toolchains [maven-toolchains-plugin]
rmannibucau commented on PR #14: URL: https://github.com/apache/maven-toolchains-plugin/pull/14#issuecomment-1962954120 Cant we make toolchain.xml physically optional and replaced by some env var naming convention instead? This way these new mojos are not needed and therefore no need to maintain the generated value which is a challenge to maintain until you make toolchain.xml an useless indirection using vars from my XP. Sounds more natural to integrate with specific setups and CI and requires less effort for us IMHO. -- 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] (MDEP-907) annotationProcessorPaths from maven-compiler-plugin are not resolved when using dependency:go-offline
[
https://issues.apache.org/jira/browse/MDEP-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MDEP-907:
-
Component/s: go-offline
> annotationProcessorPaths from maven-compiler-plugin are not resolved when
> using dependency:go-offline
> -
>
> Key: MDEP-907
> URL: https://issues.apache.org/jira/browse/MDEP-907
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: go-offline
>Reporter: Filip Hrisafov
>Priority: Major
>
> I am creating this bug in the Maven Compiler Plugin. However, I am not sure
> whether this is the right place. I appologize in advance if this is the wrong
> project.
>
> I have noticed that using {{mvn dependency:go-offline}} will not resolve the
> dependencies defined in the {{annotationProcessorPaths}} of the
> maven-compiler-plugin.
> I have created
> https://github.com/filiphr/maven-dependency-offline-annotation-processor-paths
> that demonstrates the problem.
> I've had a look at MCOMPILER-391, but I don't think that this is related to
> this one. However, I also found MNG-6877 which might solve the problem if
> there is a dedicated scope for annotation processing and then the
> maven-dependency-plugin will correctly be able to resolve the annotation
> processors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (MDEP-907) annotationProcessorPaths from maven-compiler-plugin are not resolved when using dependency:go-offline
[
https://issues.apache.org/jira/browse/MDEP-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski moved MCOMPILER-571 to MDEP-907:
Key: MDEP-907 (was: MCOMPILER-571)
Project: Maven Dependency Plugin (was: Maven Compiler Plugin)
> annotationProcessorPaths from maven-compiler-plugin are not resolved when
> using dependency:go-offline
> -
>
> Key: MDEP-907
> URL: https://issues.apache.org/jira/browse/MDEP-907
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Reporter: Filip Hrisafov
>Priority: Major
>
> I am creating this bug in the Maven Compiler Plugin. However, I am not sure
> whether this is the right place. I appologize in advance if this is the wrong
> project.
>
> I have noticed that using {{mvn dependency:go-offline}} will not resolve the
> dependencies defined in the {{annotationProcessorPaths}} of the
> maven-compiler-plugin.
> I have created
> https://github.com/filiphr/maven-dependency-offline-annotation-processor-paths
> that demonstrates the problem.
> I've had a look at MCOMPILER-391, but I don't think that this is related to
> this one. However, I also found MNG-6877 which might solve the problem if
> there is a dedicated scope for annotation processing and then the
> maven-dependency-plugin will correctly be able to resolve the annotation
> processors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MARTIFACT-10) create Unit Tests
[ https://issues.apache.org/jira/browse/MARTIFACT-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MARTIFACT-10: - Labels: good-first-issue (was: ) > create Unit Tests > - > > Key: MARTIFACT-10 > URL: https://issues.apache.org/jira/browse/MARTIFACT-10 > Project: Maven Artifact Plugin > Issue Type: Wish > Components: artifact:buildinfo >Affects Versions: 3.0.0 >Reporter: Herve Boutemy >Priority: Major > Labels: good-first-issue > > hoping we can have more complete and lighter tests than current ITs run with > maven-invoker-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1338) Update groovy to 4.0.16
[ https://issues.apache.org/jira/browse/MSHARED-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1338: - Labels: good-first-issue (was: ) > Update groovy to 4.0.16 > --- > > Key: MSHARED-1338 > URL: https://issues.apache.org/jira/browse/MSHARED-1338 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-invoker >Reporter: Jorge Solórzano >Priority: Major > Labels: good-first-issue > > Update Groovy 4.0.16 to support running on JDK 22. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MARTIFACT-58) display origin of local repository artifact when comparing
[ https://issues.apache.org/jira/browse/MARTIFACT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MARTIFACT-58: - Labels: good-first-issue (was: ) > display origin of local repository artifact when comparing > -- > > Key: MARTIFACT-58 > URL: https://issues.apache.org/jira/browse/MARTIFACT-58 > Project: Maven Artifact Plugin > Issue Type: Wish > Components: artifact:compare >Affects Versions: 3.5.0 >Reporter: Herve Boutemy >Priority: Major > Labels: good-first-issue > > artifact:compare compares output from current build (available in target/) to > content from local repository > what is not easy to detect is if content from local repository comes from a > previous local "mvn install" (done recently or a long time ago) or if it was > downloaded from a remote repository > perhaps the artifact:compare can detect and display the info -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-70) Don't require a pom.xml
[ https://issues.apache.org/jira/browse/MWRAPPER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWRAPPER-70: Labels: good-first-issue up-for-grabs (was: up-for-grabs) > Don't require a pom.xml > --- > > Key: MWRAPPER-70 > URL: https://issues.apache.org/jira/browse/MWRAPPER-70 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Plugin >Affects Versions: 3.1.1 >Reporter: Falko Modler >Priority: Major > Labels: good-first-issue, up-for-grabs > > Occasionally, it would come in handy if you could run the wrapper goal > without a pom.xml to prepare a folder from scratch. > 3.1.1 fails with: "Goal requires a project to execute but there is no POM in > this directory" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MTOOLCHAINS-46) Maven Toolchains Plugin to add JDK management
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MTOOLCHAINS-46. Resolution: Won't Do Per comment below > Maven Toolchains Plugin to add JDK management > - > > Key: MTOOLCHAINS-46 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-46 > Project: Maven Toolchains Plugin > Issue Type: New Feature >Reporter: Jacky Chan >Priority: Major > > Integrated with Disco API and add JDK management, such as JDK auto download, > GraalVM support. > > The plugin prototype: https://github.com/linux-china/toolchains-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1173) New Eclipse code style formatter
[ https://issues.apache.org/jira/browse/MSHARED-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1173: - Labels: good-first-issue up-for-grabs (was: up-for-grabs) > New Eclipse code style formatter > > > Key: MSHARED-1173 > URL: https://issues.apache.org/jira/browse/MSHARED-1173 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-resources >Reporter: Slawomir Jaranowski >Priority: Major > Labels: good-first-issue, up-for-grabs > > Parent pom 38 introduce new code style, so add also new formatter for IDE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINVOKER-337) Plugin depends on plexus-container-default, which is EOL
[
https://issues.apache.org/jira/browse/MINVOKER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MINVOKER-337:
-
Labels: good-first-issue (was: )
> Plugin depends on plexus-container-default, which is EOL
>
>
> Key: MINVOKER-337
> URL: https://issues.apache.org/jira/browse/MINVOKER-337
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: good-first-issue
>
> We should exclude {{plexus-container-default}} from dependencies to avoid
> warning by Maven 3.9.2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-336) .mvn/extensions.xml from main project is used in it projects run
[ https://issues.apache.org/jira/browse/MINVOKER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MINVOKER-336: - Labels: good-first-issue (was: ) > .mvn/extensions.xml from main project is used in it projects run > > > Key: MINVOKER-336 > URL: https://issues.apache.org/jira/browse/MINVOKER-336 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 3.5.1 >Reporter: Olivier Lamy >Priority: Major > Labels: good-first-issue > > if the main project contains some extensions in the top directory > .mvn/extensions.xml this directory will be used in IT projects run. > sounds more a issue with core (e.g MNG) due to the script mvn/mvn.bat > algorithm to find .mvn directory -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7864) Fix the S390x to use IT branches
[ https://issues.apache.org/jira/browse/MNG-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MNG-7864: Assignee: Slawomir Jaranowski > Fix the S390x to use IT branches > > > Key: MNG-7864 > URL: https://issues.apache.org/jira/browse/MNG-7864 > Project: Maven > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Slawomir Jaranowski >Priority: Major > > When testing a PR, the maven-integration-testing branch with the same name > should be used instead of master if it exists. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCOMPILER-521) Documentation: option
[
https://issues.apache.org/jira/browse/MCOMPILER-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MCOMPILER-521:
--
Labels: good-first-issue (was: )
> Documentation: option
> ---
>
> Key: MCOMPILER-521
> URL: https://issues.apache.org/jira/browse/MCOMPILER-521
> Project: Maven Compiler Plugin
> Issue Type: Improvement
> Environment: MacOS 12.2
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
>Reporter: Kevin A Shaw
>Priority: Major
> Labels: good-first-issue
>
> I am working with a multi-module project and need to exclude some
> source-directories from compilation for only one module (StackOverFlow
> [posting|https://stackoverflow.com/questions/75120440/excluding-source-directory-in-maven]).
> I have seen
> [examples|https://coderanch.com/t/745331/java/Excluding-java-files-Maven-build]
> suggesting that the `maven-compiler-plugin` can exclude directories with the
> following code.
> I have searched the Apache Maven documentation
> ([link|https://maven.apache.org/plugins/maven-compiler-plugin/index.html])
> but this is never mentioned. Is this actually a supported option? If so,
> could a reference to it be added to the documentation. It would make
> searching on it so much easier. \{{}}
> {code:java}
>
> maven-compiler-plugin
> 3.8.0
>
>
> /com/company/conflict-dir/
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Edit and update [maven-site]
elharo opened a new pull request, #494: URL: https://github.com/apache/maven-site/pull/494 Focus the description on how this is used by the developer rather than by Maven. Also, Java 5 is a little old, and sun is defunct. @hboutemy -- 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] (MPH-204) Use pluginRepositories not repositories
[ https://issues.apache.org/jira/browse/MPH-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MPH-204: Labels: good-first-issue (was: ) > Use pluginRepositories not repositories > --- > > Key: MPH-204 > URL: https://issues.apache.org/jira/browse/MPH-204 > Project: Maven Help Plugin > Issue Type: Bug > Components: describe >Affects Versions: 3.4.0 >Reporter: Delany >Priority: Major > Labels: good-first-issue > > The describe goal should retrieve the requested artifact from the available > pluginRepositories, not from repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINVOKER-335) Symlinks from source project are copied as file
[
https://issues.apache.org/jira/browse/MINVOKER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MINVOKER-335:
-
Labels: good-first-issue (was: )
> Symlinks from source project are copied as file
> ---
>
> Key: MINVOKER-335
> URL: https://issues.apache.org/jira/browse/MINVOKER-335
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: good-first-issue
>
> Source project:
> {noformat}
> -rw-r--r-- 1 xxx 40 May 1 18:44 test.txt
> drwxr-xr-x 2 xxx 64 May 1 19:26 testDir
> lrwxr-xr-x 1 xxx 7 May 1 19:27 testDirLink -> testDir
> lrwxr-xr-x 1 xxx 8 May 1 19:29 testLink.txt -> test.txt
> {noformat}
> after copy in {{target/it/..}}
> {noformat}
> -rw-r--r-- 1 xxx 40 May 1 18:44 test.txt
> drwxr-xr-x 2 xxx 64 May 1 19:30 testDir
> lrwxr-xr-x 1 xxx 7 May 1 19:30 testDirLink -> testDir
> -rw-r--r-- 1 xxx 40 May 1 18:44 testLink.txt
> {noformat}
> symlinks for directory are preserved only symlinks for file are broken
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWAR-468) document System Requirements History (JDK/Maven)
[ https://issues.apache.org/jira/browse/MWAR-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWAR-468: - Labels: good-first-issue (was: ) > document System Requirements History (JDK/Maven) > > > Key: MWAR-468 > URL: https://issues.apache.org/jira/browse/MWAR-468 > Project: Maven WAR Plugin > Issue Type: Task >Affects Versions: 3.4.0 >Reporter: Herve Boutemy >Priority: Major > Labels: good-first-issue > Fix For: next-release > > > based on MPLUGIN-400 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINVOKER-349) document System Requirements History (JDK/Maven)
[ https://issues.apache.org/jira/browse/MINVOKER-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MINVOKER-349: - Labels: good-first-issue (was: ) > document System Requirements History (JDK/Maven) > > > Key: MINVOKER-349 > URL: https://issues.apache.org/jira/browse/MINVOKER-349 > Project: Maven Invoker Plugin > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Herve Boutemy >Priority: Major > Labels: good-first-issue > > based on MPLUGIN-400 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCOMPILER-533) Output an error when --release option is used together with --source or --target
[
https://issues.apache.org/jira/browse/MCOMPILER-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MCOMPILER-533:
--
Fix Version/s: waiting-for-feedback
> Output an error when --release option is used together with --source or
> --target
>
>
> Key: MCOMPILER-533
> URL: https://issues.apache.org/jira/browse/MCOMPILER-533
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.11.0
>Reporter: Arend v. Reinersdorff
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> javac outputs an error when the --release option is used together with the
> --source or --target option. See
> [https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#option-release]
> For example:
> {{javac --release 17 --target 17 ...}}
> Will fail with this error:
> {{error: option --target cannot be used together with --release}}
> This is nice because it informs the user of misconfiguration and enforces the
> use of only \-\-release or only \-\-source/--target.
> Unfortunately, the error is lost when compiling with Maven. Maven uses the
> release option and silently ignores source and target. Users don't notice
> when they unnecessarily set both. See for example
> [https://github.com/spring-projects/spring-boot/pull/34761]
> For example:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-compiler-plugin}}
> {{ 3.11.0}}
> {{ }}
> {{ 17}}
> {{ 17}}
> {{ 17}}
> {{ }}
> {{}}
> Compiles using the release option without any error or warning.
> It would be nice to restore the error from javac in Maven, or output a
> similar one.
> The problem I see is that Maven uses default values for source and target.
> When the user sets only the release option, no error or warning should be
> caused because of the default values for source and target.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-533) Output an error when --release option is used together with --source or --target
[
https://issues.apache.org/jira/browse/MCOMPILER-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820473#comment-17820473
]
Slawomir Jaranowski commented on MCOMPILER-533:
---
Many projects use as default source/target and in profile with JDK 9+ add also
release.
When we generate warning we will force user to preparing more complicated
configurations with more profiles.
Even more we next version of compiler we will can provided all parameter
without profiles.
> Output an error when --release option is used together with --source or
> --target
>
>
> Key: MCOMPILER-533
> URL: https://issues.apache.org/jira/browse/MCOMPILER-533
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.11.0
>Reporter: Arend v. Reinersdorff
>Priority: Major
>
> javac outputs an error when the --release option is used together with the
> --source or --target option. See
> [https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#option-release]
> For example:
> {{javac --release 17 --target 17 ...}}
> Will fail with this error:
> {{error: option --target cannot be used together with --release}}
> This is nice because it informs the user of misconfiguration and enforces the
> use of only \-\-release or only \-\-source/--target.
> Unfortunately, the error is lost when compiling with Maven. Maven uses the
> release option and silently ignores source and target. Users don't notice
> when they unnecessarily set both. See for example
> [https://github.com/spring-projects/spring-boot/pull/34761]
> For example:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-compiler-plugin}}
> {{ 3.11.0}}
> {{ }}
> {{ 17}}
> {{ 17}}
> {{ 17}}
> {{ }}
> {{}}
> Compiles using the release option without any error or warning.
> It would be nice to restore the error from javac in Maven, or output a
> similar one.
> The problem I see is that Maven uses default values for source and target.
> When the user sets only the release option, no error or warning should be
> caused because of the default values for source and target.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSCRIPTING-13) Remove unused dependencies
[ https://issues.apache.org/jira/browse/MSCRIPTING-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSCRIPTING-13: -- Labels: good-first-issue (was: ) > Remove unused dependencies > -- > > Key: MSCRIPTING-13 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-13 > Project: Maven Scripting > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > Labels: good-first-issue > > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.maven.shared:maven-shared-utils:jar:3.3.3:compile > [WARNING]junit:junit:jar:4.12:test > [WARNING] > org.apache.maven.plugin-testing:maven-plugin-testing-harness:jar:2.1:test > [WARNING]org.apache.maven:maven-compat:jar:3.0:test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSITE-945) Remove dependency on Commons IO
[ https://issues.apache.org/jira/browse/MSITE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSITE-945: -- Labels: good-first-issue (was: ) > Remove dependency on Commons IO > --- > > Key: MSITE-945 > URL: https://issues.apache.org/jira/browse/MSITE-945 > Project: Maven Site Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > Labels: good-first-issue > > All uses look easily replaceable by standard JDK methods these days -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-301) Artifact Generators
[ https://issues.apache.org/jira/browse/MRESOLVER-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820471#comment-17820471 ] ASF GitHub Bot commented on MRESOLVER-301: -- gnodet commented on PR #432: URL: https://github.com/apache/maven-resolver/pull/432#issuecomment-1962938412 > > Now that you put it that way, I'm not really convinced we need a Signer SPI here. The code of the ArtifactGenerator which calls the signers is trivial, so it seems to me that the GpgSigner could directly implement the Artifact Generator SPI. > > Agreed, will simplify it more, but the question begs: "generator-signer" module name becomes wrong, no? Should it be maybe "generator-gnupg (or gpg)" instead? Yes, I think that would make more sense. > Artifact Generators > --- > > Key: MRESOLVER-301 > URL: https://issues.apache.org/jira/browse/MRESOLVER-301 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-9 > > > Resolver should provide extension point for "generators". Typical use case > for these are for example "signing" of artifacts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-301] Artifact generators [maven-resolver]
gnodet commented on PR #432: URL: https://github.com/apache/maven-resolver/pull/432#issuecomment-1962938412 > > Now that you put it that way, I'm not really convinced we need a Signer SPI here. The code of the ArtifactGenerator which calls the signers is trivial, so it seems to me that the GpgSigner could directly implement the Artifact Generator SPI. > > Agreed, will simplify it more, but the question begs: "generator-signer" module name becomes wrong, no? Should it be maybe "generator-gnupg (or gpg)" instead? Yes, I think that would make more sense. -- 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] (MCOMPILER-529) Improve the docs about usage 1.8 vs. 8 for source/target
[
https://issues.apache.org/jira/browse/MCOMPILER-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MCOMPILER-529:
--
Labels: good-first-issue (was: )
> Improve the docs about usage 1.8 vs. 8 for source/target
>
>
> Key: MCOMPILER-529
> URL: https://issues.apache.org/jira/browse/MCOMPILER-529
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.10.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Labels: good-first-issue
>
> The current descriptions/docs only mentioned the usage of {{1.8}} for
> source/target. But it looks like I can use also {{8}} instead. But all the
> examples on the usage page etc. using {{1.8}}... even the error message tells
> me to do:
> {{code}}
> use -source 8 ...
> {{code}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1287) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MSHARED-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1287: - Labels: good-first-issue (was: ) > Upgrade Parent to 41 > > > Key: MSHARED-1287 > URL: https://issues.apache.org/jira/browse/MSHARED-1287 > Project: Maven Shared Components > Issue Type: Task > Components: maven-dependency-tree >Reporter: Slawomir Jaranowski >Priority: Major > Labels: good-first-issue > Fix For: maven-dependency-tree-next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1301) Upgrade Parent to 41 and cleanup
[ https://issues.apache.org/jira/browse/MSHARED-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1301: - Summary: Upgrade Parent to 41 and cleanup (was: Upgrade Parent to 39 and cleanup) > Upgrade Parent to 41 and cleanup > > > Key: MSHARED-1301 > URL: https://issues.apache.org/jira/browse/MSHARED-1301 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-common-artifact-filters >Reporter: Elliotte Rusty Harold >Priority: Major > Fix For: maven-common-artifact-filters-next-release > > Attachments: maven_parent_poms.300.png > > > will require a spotless run -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1287) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MSHARED-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1287: - Summary: Upgrade Parent to 41 (was: Upgrade Parent to 40) > Upgrade Parent to 41 > > > Key: MSHARED-1287 > URL: https://issues.apache.org/jira/browse/MSHARED-1287 > Project: Maven Shared Components > Issue Type: Task > Components: maven-dependency-tree >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: maven-dependency-tree-next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1301) Upgrade Parent to 41 and cleanup
[ https://issues.apache.org/jira/browse/MSHARED-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1301: - Labels: good-first-issue (was: ) > Upgrade Parent to 41 and cleanup > > > Key: MSHARED-1301 > URL: https://issues.apache.org/jira/browse/MSHARED-1301 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-common-artifact-filters >Reporter: Elliotte Rusty Harold >Priority: Major > Labels: good-first-issue > Fix For: maven-common-artifact-filters-next-release > > Attachments: maven_parent_poms.300.png > > > will require a spotless run -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1170) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MSHARED-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1170: - Labels: good-first-issue (was: ) > Upgrade Parent to 41 > > > Key: MSHARED-1170 > URL: https://issues.apache.org/jira/browse/MSHARED-1170 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-resources >Reporter: Slawomir Jaranowski >Priority: Major > Labels: good-first-issue > Fix For: maven-shared-resources-6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1170) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MSHARED-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1170: - Summary: Upgrade Parent to 41 (was: Upgrade Parent to 39) > Upgrade Parent to 41 > > > Key: MSHARED-1170 > URL: https://issues.apache.org/jira/browse/MSHARED-1170 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-resources >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: maven-shared-resources-6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-301) Artifact Generators
[ https://issues.apache.org/jira/browse/MRESOLVER-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820465#comment-17820465 ] ASF GitHub Bot commented on MRESOLVER-301: -- cstamas commented on PR #432: URL: https://github.com/apache/maven-resolver/pull/432#issuecomment-1962919989 > Now that you put it that way, I'm not really convinced we need a Signer SPI here. The code of the ArtifactGenerator which calls the signers is trivial, so it seems to me that the GpgSigner could directly implement the Artifact Generator SPI. Agreed, will simplify it more, but the question begs: "generator-signer" module becomes wrong, no? Should it be maybe "generator-gnupg (or gpg)" instead? > Artifact Generators > --- > > Key: MRESOLVER-301 > URL: https://issues.apache.org/jira/browse/MRESOLVER-301 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-9 > > > Resolver should provide extension point for "generators". Typical use case > for these are for example "signing" of artifacts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-301] Artifact generators [maven-resolver]
cstamas commented on PR #432: URL: https://github.com/apache/maven-resolver/pull/432#issuecomment-1962919989 > Now that you put it that way, I'm not really convinced we need a Signer SPI here. The code of the ArtifactGenerator which calls the signers is trivial, so it seems to me that the GpgSigner could directly implement the Artifact Generator SPI. Agreed, will simplify it more, but the question begs: "generator-signer" module becomes wrong, no? Should it be maybe "generator-gnupg (or gpg)" instead? -- 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-1357) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MSHARED-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1357: - Labels: good-first-issue (was: ) > Upgrade Parent to 41 > > > Key: MSHARED-1357 > URL: https://issues.apache.org/jira/browse/MSHARED-1357 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-verifier >Reporter: Slawomir Jaranowski >Priority: Major > Labels: good-first-issue > Fix For: maven-verifier-next > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-301) Artifact Generators
[ https://issues.apache.org/jira/browse/MRESOLVER-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820443#comment-17820443 ] ASF GitHub Bot commented on MRESOLVER-301: -- gnodet commented on PR #432: URL: https://github.com/apache/maven-resolver/pull/432#issuecomment-1962863211 > So to recap, what I tried to explain to Slawek. This PR: > > * defines `Artifact Generator` SPI (there may be multiple of those present in system) > * defines `Signer Artifact Generator` that is one provider for SPI, that defines Signer API (there may be multiple of those present in system) Now that you put it that way, I'm not really convinced we need a Signer SPI here. The code of the ArtifactGenerator which calls the signers is trivial, so it seems to me that the GpgSigner could directly implement the Artifact Generator SPI. > * implements GpgSigner that is one Signer implementation provided out of the box > > Naturally, as generators are ordered, signer generator is expected to be "among last" and sign not only artifacts in request (install/deploy) but also "so far generated artifacts" (if they are relevant). > Artifact Generators > --- > > Key: MRESOLVER-301 > URL: https://issues.apache.org/jira/browse/MRESOLVER-301 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-9 > > > Resolver should provide extension point for "generators". Typical use case > for these are for example "signing" of artifacts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-301] Artifact generators [maven-resolver]
gnodet commented on PR #432: URL: https://github.com/apache/maven-resolver/pull/432#issuecomment-1962863211 > So to recap, what I tried to explain to Slawek. This PR: > > * defines `Artifact Generator` SPI (there may be multiple of those present in system) > * defines `Signer Artifact Generator` that is one provider for SPI, that defines Signer API (there may be multiple of those present in system) Now that you put it that way, I'm not really convinced we need a Signer SPI here. The code of the ArtifactGenerator which calls the signers is trivial, so it seems to me that the GpgSigner could directly implement the Artifact Generator SPI. > * implements GpgSigner that is one Signer implementation provided out of the box > > Naturally, as generators are ordered, signer generator is expected to be "among last" and sign not only artifacts in request (install/deploy) but also "so far generated artifacts" (if they are relevant). -- 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] (MWAR-471) normalize file permissions on dependencies copied to WEB-INF/lib
[ https://issues.apache.org/jira/browse/MWAR-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820395#comment-17820395 ] Herve Boutemy edited comment on MWAR-471 at 2/25/24 8:28 AM: - bq. building on Windows with WLS sharing a disk with for the local repository with the Windows machine I suppose it's the same when you mount a smb disk, that does not track Unix permissions: there is a common permission assigned https://sysadmins.tech/linux-and-cifs-files-permissions/ was (Author: hboutemy): bq. building on Windows with WLS sharing a disk with for the local repository with the Windows machine I suppose it's the same when you mount a smb disk, that does not track Unix permissions: there is a common permission assigned > normalize file permissions on dependencies copied to WEB-INF/lib > > > Key: MWAR-471 > URL: https://issues.apache.org/jira/browse/MWAR-471 > Project: Maven WAR Plugin > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Herve Boutemy >Priority: Major > > as seen on Jackrabbit releases > https://lists.apache.org/thread/6qxnclwmxggq6j20l8z78yr375vxo508, building on > Windows with WLS sharing a disk with for the local repository with the > Windows machine leads to executable permission on dependency jars copied to > WEB-INF/lib > normalizing permissions during the copy from local repo to WEB-INF/lib looks > reasonable to solve that environment edge case -- This message was sent by Atlassian Jira (v8.20.10#820010)
