[jira] [Commented] (MSHARED-1327) Change output directory default in AbstractMavenReport
[
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785137#comment-17785137
]
ASF GitHub Bot commented on MSHARED-1327:
-
kriegaex commented on PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1806677901
> I still stand with `reports`.
I rebased and force-pushed the PR with the updated directory.
> Though, I need to test the entire chain first.
I am not sure what that means, but it sounds like due diligence, which is a
good thing.
> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution,
> a plugin should not mess with Maven Site's default directory. Imagine a
> situation in which each module should get its own, self-consistent report
> when called stand-alone, but the site should contain an aggregate with a
> different structure or maybe no report from that plugin at all. The default
> would then pollute the site directory. This is why on the ML I asked you
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class
> field by another {{@Parameter}} annotation on a setter in a subclass it is
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not
> use the abstract base class, implements the default correctly: build dir for
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site
> generation context, the reporting base directory will be set here
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1327] Change output directory default [maven-reporting-impl]
kriegaex commented on PR #26: URL: https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1806677901 > I still stand with `reports`. I rebased and force-pushed the PR with the updated directory. > Though, I need to test the entire chain first. I am not sure what that means, but it sounds like due diligence, which is a good thing. -- 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] (MSHADE-406) relocated multi-release classes aren't moved to a new directory
[
https://issues.apache.org/jira/browse/MSHADE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785091#comment-17785091
]
ASF GitHub Bot commented on MSHADE-406:
---
nielsbasjes commented on PR #202:
URL:
https://github.com/apache/maven-shade-plugin/pull/202#issuecomment-1806561815
Current state is with https://github.com/tcurdt/jdependency/pull/209
installed almost all tests (including several new tests that do shading,
relocating and minimizing a multirelease jar) pass. Only a few around the
MANIFEST.MF tests currently fail.
```
[INFO] Passed: 79, Failed: 3, Errors: 0, Skipped: 1
[INFO] -
[ERROR] The following builds failed:
[ERROR] * projects/MSHADE-373/pom.xml
[ERROR] * projects/MSHADE-183/pom.xml
[ERROR] * projects/manifest-transformed/pom.xml
[INFO] -
[WARNING] The following builds were skipped:
[WARNING] * projects/MSHADE-185/pom.xml
```
> relocated multi-release classes aren't moved to a new directory
> ---
>
> Key: MSHADE-406
> URL: https://issues.apache.org/jira/browse/MSHADE-406
> Project: Maven Shade Plugin
> Issue Type: Bug
>Reporter: Brian Gruber
>Priority: Major
>
> In a project in which a dependency has a multi-release jar, classes that
> match a relocation pattern and are in the {{META-INF/versions}} directories
> are not moved to the new directory structure. They are, however, rewritten so
> that the class file itself specifies the new package name.
> Sample project:
> [https://gist.github.com/bgruber/5fb045759505da5150d3e93ec5c6010e]
> The generated jar file still contains classes like this:
> {code:java}
> $ jar tf target/relocation-test-SNAPSHOT-1.0.jar | grep versions | head
> META-INF/versions/
> META-INF/versions/9/
> META-INF/versions/9/org/
> META-INF/versions/9/org/bouncycastle/
> META-INF/versions/9/org/bouncycastle/crypto/
> META-INF/versions/9/org/bouncycastle/crypto/AsymmetricCipherKeyPair.class
> META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> META-INF/versions/9/org/bouncycastle/crypto/CryptoServicesRegistrar$Property.class
> META-INF/versions/9/org/bouncycastle/crypto/CryptoServicesRegistrar.class
> META-INF/versions/9/org/bouncycastle/crypto/KeyGenerationParameters.class{code}
> I expect these class files to be under
> {{META-INF/versions/9/com/dd/org/bouncycastle}}. Extracting one of them from
> the jar and examining it, the class file does appear to have been modified to
> have the new package name:
> {code:java}
> $ jar xf target/relocation-test-SNAPSHOT-1.0.jar
> META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> $ javap META-INF/versions/9/org/bouncycastle/crypto/Digest.class
> Compiled from "Digest.java"
> public interface com.dd.org.bouncycastle.crypto.Digest {
> public abstract java.lang.String getAlgorithmName();
> public abstract int getDigestSize();
> public abstract void update(byte);
> public abstract void update(byte[], int, int);
> public abstract int doFinal(byte[], int);
> public abstract void reset();
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHADE-406] Support multi release jars [maven-shade-plugin]
nielsbasjes commented on PR #202: URL: https://github.com/apache/maven-shade-plugin/pull/202#issuecomment-1806561815 Current state is with https://github.com/tcurdt/jdependency/pull/209 installed almost all tests (including several new tests that do shading, relocating and minimizing a multirelease jar) pass. Only a few around the MANIFEST.MF tests currently fail. ``` [INFO] Passed: 79, Failed: 3, Errors: 0, Skipped: 1 [INFO] - [ERROR] The following builds failed: [ERROR] * projects/MSHADE-373/pom.xml [ERROR] * projects/MSHADE-183/pom.xml [ERROR] * projects/manifest-transformed/pom.xml [INFO] - [WARNING] The following builds were skipped: [WARNING] * projects/MSHADE-185/pom.xml ``` -- 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-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785087#comment-17785087 ] ASF GitHub Bot commented on MPLUGIN-450: gnodet opened a new pull request, #240: URL: https://github.com/apache/maven-plugin-tools/pull/240 (no comment) > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-994) Items from unpacked dependency are not refreshed
[
https://issues.apache.org/jira/browse/MASSEMBLY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785071#comment-17785071
]
Slawomir Jaranowski commented on MASSEMBLY-994:
---
We have an option {{updateOnly}} which is set by default to {{false}}, after
fix in plexus-archives we can add IT for confirmation.
> Items from unpacked dependency are not refreshed
>
>
> Key: MASSEMBLY-994
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-994
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> For assembly descriptor like:
> {code:java}
>
> dir
>
>
>
>
> groupId:ArtifactId
>
> true
>
>
> {code}
> Where {{groupId:ArtifactId}} comes from reactor build, even when content of
> artifact was changed, items in destination directory contains old files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-994) Items from unpacked dependency are not refreshed
[
https://issues.apache.org/jira/browse/MASSEMBLY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785069#comment-17785069
]
ASF GitHub Bot commented on MASSEMBLY-994:
--
slawekjaranowski opened a new pull request, #164:
URL: https://github.com/apache/maven-assembly-plugin/pull/164
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MASSEMBLY) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MASSEMBLY-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MASSEMBLY-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> Items from unpacked dependency are not refreshed
>
>
> Key: MASSEMBLY-994
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-994
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> For assembly descriptor like:
> {code:java}
>
> dir
>
>
>
>
> groupId:ArtifactId
>
> true
>
>
> {code}
> Where {{groupId:ArtifactId}} comes from reactor build, even when content of
> artifact was changed, items in destination directory contains old files.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MASSEMBLY-994] IT - refresh unpacked dependencies in dir archive [maven-assembly-plugin]
slawekjaranowski opened a new pull request, #164: URL: https://github.com/apache/maven-assembly-plugin/pull/164 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MASSEMBLY) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MASSEMBLY-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MASSEMBLY-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-894) Use @Component instead of @Parameter for session/project
[
https://issues.apache.org/jira/browse/MDEP-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785065#comment-17785065
]
Slawomir Jaranowski commented on MDEP-894:
--
Now we have a warnings:
{code}
[WARNING] Deprecated @Component annotation for 'project' field in
org.apache.maven.plugins.dependency.resolvers.CollectDependenciesMojo: replace
with @Parameter( defaultValue = "${project}", readonly = true )
[WARNING] Deprecated @Component annotation for 'session' field in
org.apache.maven.plugins.dependency.resolvers.CollectDependenciesMojo: replace
with @Parameter( defaultValue = "${session}", readonly = true )
{code}
> Use @Component instead of @Parameter for session/project
>
>
> Key: MDEP-894
> URL: https://issues.apache.org/jira/browse/MDEP-894
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.2
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MDEP-895) dependency:sources fails for multi-module project
[
https://issues.apache.org/jira/browse/MDEP-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MDEP-895:
Assignee: Slawomir Jaranowski
> dependency:sources fails for multi-module project
> -
>
> Key: MDEP-895
> URL: https://issues.apache.org/jira/browse/MDEP-895
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 3.6.1
>Reporter: Gerd Aschemann
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Fix For: 3.6.2
>
>
> When executing `mvn dependency:sources` on a multi-module project it fails to
> retrieve sources for the modules themselves (which is not necessary as the
> source code is provided locally already):
> {code:java}
> mvn dependency:sources
> ...
> [INFO] -< org.apache.maven.its.dependency:tree-multimodule-module-b
> >--
> [INFO] Building MultimoduleTest Module B 1.0-SNAPSHOT
> [3/3]
> [INFO] from module-b/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] Reactor Summary for MultimoduleTest 1.0-SNAPSHOT:
> [INFO]
> [INFO] MultimoduleTest SUCCESS [ 0.390
> s]
> [INFO] MultimoduleTest Module A ... SUCCESS [ 0.063
> s]
> [INFO] MultimoduleTest Module B ... FAILURE [ 0.005
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.587 s
> [INFO] Finished at: 2023-11-09T10:38:16+01:00
> [INFO]
>
> [ERROR] Failed to execute goal on project tree-multimodule-module-b: Could
> not resolve dependencies for project
> org.apache.maven.its.dependency:tree-multimodule-module-b:jar:1.0-SNAPSHOT:
> The following artifacts could not be resolved:
> org.apache.maven.its.dependency:tree-multimodule-module-a:jar:1.0-SNAPSHOT
> (absent): Could not find artifact
> org.apache.maven.its.dependency:tree-multimodule-module-a:jar:1.0-SNAPSHOT ->
> [Help 1]{code}
> This is similar to the behaviour of MDEP-409.
> A test and PR is already prepared:
> https://github.com/jmle/maven-dependency-plugin/tree/fix-sources-multimodule
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MDEP-895) dependency:sources fails for multi-module project
[
https://issues.apache.org/jira/browse/MDEP-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MDEP-895.
Fix Version/s: 3.6.2
Resolution: Fixed
> dependency:sources fails for multi-module project
> -
>
> Key: MDEP-895
> URL: https://issues.apache.org/jira/browse/MDEP-895
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 3.6.1
>Reporter: Gerd Aschemann
>Priority: Critical
> Fix For: 3.6.2
>
>
> When executing `mvn dependency:sources` on a multi-module project it fails to
> retrieve sources for the modules themselves (which is not necessary as the
> source code is provided locally already):
> {code:java}
> mvn dependency:sources
> ...
> [INFO] -< org.apache.maven.its.dependency:tree-multimodule-module-b
> >--
> [INFO] Building MultimoduleTest Module B 1.0-SNAPSHOT
> [3/3]
> [INFO] from module-b/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] Reactor Summary for MultimoduleTest 1.0-SNAPSHOT:
> [INFO]
> [INFO] MultimoduleTest SUCCESS [ 0.390
> s]
> [INFO] MultimoduleTest Module A ... SUCCESS [ 0.063
> s]
> [INFO] MultimoduleTest Module B ... FAILURE [ 0.005
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.587 s
> [INFO] Finished at: 2023-11-09T10:38:16+01:00
> [INFO]
>
> [ERROR] Failed to execute goal on project tree-multimodule-module-b: Could
> not resolve dependencies for project
> org.apache.maven.its.dependency:tree-multimodule-module-b:jar:1.0-SNAPSHOT:
> The following artifacts could not be resolved:
> org.apache.maven.its.dependency:tree-multimodule-module-a:jar:1.0-SNAPSHOT
> (absent): Could not find artifact
> org.apache.maven.its.dependency:tree-multimodule-module-a:jar:1.0-SNAPSHOT ->
> [Help 1]{code}
> This is similar to the behaviour of MDEP-409.
> A test and PR is already prepared:
> https://github.com/jmle/maven-dependency-plugin/tree/fix-sources-multimodule
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MDEP-895] - dependency:sources fails for multi-module project [maven-dependency-plugin]
slawekjaranowski merged PR #349: URL: https://github.com/apache/maven-dependency-plugin/pull/349 -- 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] (MDEP-895) dependency:sources fails for multi-module project
[
https://issues.apache.org/jira/browse/MDEP-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785061#comment-17785061
]
ASF GitHub Bot commented on MDEP-895:
-
slawekjaranowski merged PR #349:
URL: https://github.com/apache/maven-dependency-plugin/pull/349
> dependency:sources fails for multi-module project
> -
>
> Key: MDEP-895
> URL: https://issues.apache.org/jira/browse/MDEP-895
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 3.6.1
>Reporter: Gerd Aschemann
>Priority: Critical
>
> When executing `mvn dependency:sources` on a multi-module project it fails to
> retrieve sources for the modules themselves (which is not necessary as the
> source code is provided locally already):
> {code:java}
> mvn dependency:sources
> ...
> [INFO] -< org.apache.maven.its.dependency:tree-multimodule-module-b
> >--
> [INFO] Building MultimoduleTest Module B 1.0-SNAPSHOT
> [3/3]
> [INFO] from module-b/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] Reactor Summary for MultimoduleTest 1.0-SNAPSHOT:
> [INFO]
> [INFO] MultimoduleTest SUCCESS [ 0.390
> s]
> [INFO] MultimoduleTest Module A ... SUCCESS [ 0.063
> s]
> [INFO] MultimoduleTest Module B ... FAILURE [ 0.005
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.587 s
> [INFO] Finished at: 2023-11-09T10:38:16+01:00
> [INFO]
>
> [ERROR] Failed to execute goal on project tree-multimodule-module-b: Could
> not resolve dependencies for project
> org.apache.maven.its.dependency:tree-multimodule-module-b:jar:1.0-SNAPSHOT:
> The following artifacts could not be resolved:
> org.apache.maven.its.dependency:tree-multimodule-module-a:jar:1.0-SNAPSHOT
> (absent): Could not find artifact
> org.apache.maven.its.dependency:tree-multimodule-module-a:jar:1.0-SNAPSHOT ->
> [Help 1]{code}
> This is similar to the behaviour of MDEP-409.
> A test and PR is already prepared:
> https://github.com/jmle/maven-dependency-plugin/tree/fix-sources-multimodule
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-895) dependency:sources fails for multi-module project
[
https://issues.apache.org/jira/browse/MDEP-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785038#comment-17785038
]
ASF GitHub Bot commented on MDEP-895:
-
ascheman commented on PR #349:
URL:
https://github.com/apache/maven-dependency-plugin/pull/349#issuecomment-1806217963
Thanks, @slawekjaranowski
> dependency:sources fails for multi-module project
> -
>
> Key: MDEP-895
> URL: https://issues.apache.org/jira/browse/MDEP-895
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 3.6.1
>Reporter: Gerd Aschemann
>Priority: Critical
>
> When executing `mvn dependency:sources` on a multi-module project it fails to
> retrieve sources for the modules themselves (which is not necessary as the
> source code is provided locally already):
> {code:java}
> mvn dependency:sources
> ...
> [INFO] -< org.apache.maven.its.dependency:tree-multimodule-module-b
> >--
> [INFO] Building MultimoduleTest Module B 1.0-SNAPSHOT
> [3/3]
> [INFO] from module-b/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] Reactor Summary for MultimoduleTest 1.0-SNAPSHOT:
> [INFO]
> [INFO] MultimoduleTest SUCCESS [ 0.390
> s]
> [INFO] MultimoduleTest Module A ... SUCCESS [ 0.063
> s]
> [INFO] MultimoduleTest Module B ... FAILURE [ 0.005
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.587 s
> [INFO] Finished at: 2023-11-09T10:38:16+01:00
> [INFO]
>
> [ERROR] Failed to execute goal on project tree-multimodule-module-b: Could
> not resolve dependencies for project
> org.apache.maven.its.dependency:tree-multimodule-module-b:jar:1.0-SNAPSHOT:
> The following artifacts could not be resolved:
> org.apache.maven.its.dependency:tree-multimodule-module-a:jar:1.0-SNAPSHOT
> (absent): Could not find artifact
> org.apache.maven.its.dependency:tree-multimodule-module-a:jar:1.0-SNAPSHOT ->
> [Help 1]{code}
> This is similar to the behaviour of MDEP-409.
> A test and PR is already prepared:
> https://github.com/jmle/maven-dependency-plugin/tree/fix-sources-multimodule
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MDEP-895] - dependency:sources fails for multi-module project [maven-dependency-plugin]
ascheman commented on PR #349: URL: https://github.com/apache/maven-dependency-plugin/pull/349#issuecomment-1806217963 Thanks, @slawekjaranowski -- 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: [I] Failed to install artifact xxx [maven-mvnd]
slawekjaranowski commented on issue #862: URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1806212777 It can be connected with https://issues.apache.org/jira/browse/MRESOLVER-372 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785037#comment-17785037
]
Slawomir Jaranowski commented on MRESOLVER-372:
---
Next case - I think connected: https://github.com/apache/maven-mvnd/issues/862
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [I] Failed to install artifact xxx [maven-mvnd]
harryssuperman commented on issue #862: URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1806160052 Hi folks, i had the same issue with latest local maven 3.9.5. I was looking at unsere CI System and in the last few weeks was the same problem but with the maven 3.9.3. Because it was an AccesDeniedException i was thinking about Windows File System Policy or something like that. I was deleting the complete repository and build was again fine. I will update you if problem continues or maybe not anymore. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7925) Global model cache with maven extensions fails to track the source location
Jonas Rutishauser created MNG-7925:
--
Summary: Global model cache with maven extensions fails to track
the source location
Key: MNG-7925
URL: https://issues.apache.org/jira/browse/MNG-7925
Project: Maven
Issue Type: Bug
Affects Versions: 3.9.5
Reporter: Jonas Rutishauser
If we have a parent pom like this:
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
test
cache-bug-parent
1.0.0-SNAPSHOT
pom
maven-install-plugin
3.1.1
{code}
And we have a project pom which uses this parent pom whilst an extension
(declared in {{.mvn/extensions.xml}}) uses the same parent, the global model
cache is the reason that the source location is lost.
To reproduce the bug the following projects can be used:
- The extension (empty jar is enough):
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
test
cache-bug-parent
1.0.0-SNAPSHOT
cache-bug-extension
{code}
- The test project:
{{.mvn/extensions.xml}}:
{code:xml}
http://maven.apache.org/EXTENSIONS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
http://maven.apache.org/xsd/core-extensions-1.0.0.xsd;>
test
cache-bug-extension
1.0.0-SNAPSHOT
{code}
{{pom.xml}}:
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
test
cache-bug-parent
1.0.0-SNAPSHOT
cache-bug
pom
maven-enforcer-plugin
3.4.1
enforce-version
enforce
org.apache.maven.plugins:maven-enforcer-plugin
org.apache.maven.plugins:maven-clean-plugin,org.apache.maven.plugins:maven-deploy-plugin,org.apache.maven.plugins:maven-site-plugin
{code}
The test project can be built with {{mvn clean verify
-Dmaven.defaultProjectBuilder.disableGlobalModelCache=true}}, but fails with
{{mvn clean verify}}.
The enforcer plugin uses the source location to determine from which location
the plugin declaration comes from.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784998#comment-17784998
]
ASF GitHub Bot commented on MNG-7924:
-
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1389639253
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultDependencyProperties.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.api.DependencyProperties;
+import org.apache.maven.api.annotations.Nonnull;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+/**
+ * Default implementation of artifact properties.
+ */
+public class DefaultDependencyProperties implements DependencyProperties {
+private final Map properties;
+
+public DefaultDependencyProperties(String... flags) {
+this(Arrays.asList(flags));
Review Comment:
Object... never can be null, it will be `[]` (empty array) at most
> Better control over and better integration with Resolver
>
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did
> stem from "[JPMS module
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support];
> and are considered improvement but *does not implement any functionality*
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new
> artifact types (fully in extension, and extension should get extended data
> via "roundtrip" in core/resolver)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
cstamas commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1389639253
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultDependencyProperties.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.api.DependencyProperties;
+import org.apache.maven.api.annotations.Nonnull;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+/**
+ * Default implementation of artifact properties.
+ */
+public class DefaultDependencyProperties implements DependencyProperties {
+private final Map properties;
+
+public DefaultDependencyProperties(String... flags) {
+this(Arrays.asList(flags));
Review Comment:
Object... never can be null, it will be `[]` (empty array) at most
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver
[
https://issues.apache.org/jira/browse/MNG-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784994#comment-17784994
]
ASF GitHub Bot commented on MNG-7924:
-
gnodet commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1389597488
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultDependencyProperties.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.api.DependencyProperties;
+import org.apache.maven.api.annotations.Nonnull;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+/**
+ * Default implementation of artifact properties.
+ */
+public class DefaultDependencyProperties implements DependencyProperties {
+private final Map properties;
+
+public DefaultDependencyProperties(String... flags) {
+this(Arrays.asList(flags));
Review Comment:
`nonNull(flags)` or add an `if (flags != null)` ?
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultDependencyProperties.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.api.DependencyProperties;
+import org.apache.maven.api.annotations.Nonnull;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+/**
+ * Default implementation of artifact properties.
+ */
+public class DefaultDependencyProperties implements DependencyProperties {
+private final Map properties;
+
+public DefaultDependencyProperties(String... flags) {
+this(Arrays.asList(flags));
+}
+
+public DefaultDependencyProperties(Collection flags) {
+HashMap map = new HashMap<>();
+for (String flag : flags) {
Review Comment:
`nonNull(flags)` or add an `if (flags != null)` ?
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultDependencyProperties.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.api.DependencyProperties;
+import
Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]
gnodet commented on code in PR #1299:
URL: https://github.com/apache/maven/pull/1299#discussion_r1389597488
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultDependencyProperties.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.api.DependencyProperties;
+import org.apache.maven.api.annotations.Nonnull;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+/**
+ * Default implementation of artifact properties.
+ */
+public class DefaultDependencyProperties implements DependencyProperties {
+private final Map properties;
+
+public DefaultDependencyProperties(String... flags) {
+this(Arrays.asList(flags));
Review Comment:
`nonNull(flags)` or add an `if (flags != null)` ?
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultDependencyProperties.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.api.DependencyProperties;
+import org.apache.maven.api.annotations.Nonnull;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+/**
+ * Default implementation of artifact properties.
+ */
+public class DefaultDependencyProperties implements DependencyProperties {
+private final Map properties;
+
+public DefaultDependencyProperties(String... flags) {
+this(Arrays.asList(flags));
+}
+
+public DefaultDependencyProperties(Collection flags) {
+HashMap map = new HashMap<>();
+for (String flag : flags) {
Review Comment:
`nonNull(flags)` or add an `if (flags != null)` ?
##
maven-core/src/main/java/org/apache/maven/internal/impl/DefaultDependencyProperties.java:
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.internal.impl;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.maven.api.DependencyProperties;
+import org.apache.maven.api.annotations.Nonnull;
+
+import static org.apache.maven.internal.impl.Utils.nonNull;
+
+/**
+ * Default implementation of artifact properties.
+ */
+public class DefaultDependencyProperties implements DependencyProperties {
+
[jira] [Updated] (MNG-7914) Provide a single entry point for configuration
[
https://issues.apache.org/jira/browse/MNG-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7914:
-
Description:
Looking at MNG-7772, this should not require any code change, but it's all
about configuration.
I propose to load / interpolate the following files:
* {{${maven.home}/conf/maven.user.properties}}
* {{${maven.home}/conf/maven.system.properties}}
Those files would be used to load additional user properties and system
properties for Maven. In addition to the simple interpolation mechanism, we
should provide two enhancements using special keys {{{}$\{includes{ and
{{{}$\{optionals{ which would be used to load additional referenced
configuration files such as:
{{ ${optionals} = ${user.home}/.m2/maven.user.properties,
${session.rootDirectory}/.mvn/maven.user.properties}}
Being loaded early when Maven is loaded, those files could reference
directories to load extensions from:
{{{}maven.core.extensions.directories =
${session.rootDirectory}/.mvn/extensions.xml,{}}}{{{}${user.home}/.m2/extensions.xml,${maven.home}/extensions.xml{}}}
In various places, the maven code could be simplified and offer more
configuration points at the same time.
was:
Looking at MNG-7772, this should not require any code change, but it's all
about configuration.
I propose to load / interpolate the following files:
* {{${maven.home}/conf/maven.user.properties}}
* {{${maven.home}/conf/maven.system.properties}}
Those files would be used to load additional user properties and system
properties for Maven. In addition to the simple interpolation mechanism, we
should provide two enhancements using special keys {{${includes}}} and
{{${optionals}}} which would be used to load additional referenced
configuration files such as:
{{{} ${optionals} = ${user.home}/.m2/maven.user.properties,
${session.rootDirectory}/.mvn/maven.user.properties{}}}{{{}{}}}{{{}{}}}
Being loaded early when Maven is loaded, those files could reference
directories to load extensions from:
{{{}maven.core.extensions.directories =
{{{}${session.rootDirectory}/.mvn/extensions.xml,{}}}{{{}${user.home}/.m2/extensions.xml,${maven.home}/extensions.xml{}}}{}}}{{{}{}}}
In various places, the maven code could be simplified and offer more
configuration points at the same time.
> Provide a single entry point for configuration
> --
>
> Key: MNG-7914
> URL: https://issues.apache.org/jira/browse/MNG-7914
> Project: Maven
> Issue Type: New Feature
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Looking at MNG-7772, this should not require any code change, but it's all
> about configuration.
> I propose to load / interpolate the following files:
> * {{${maven.home}/conf/maven.user.properties}}
> * {{${maven.home}/conf/maven.system.properties}}
> Those files would be used to load additional user properties and system
> properties for Maven. In addition to the simple interpolation mechanism, we
> should provide two enhancements using special keys {{{}$\{includes{ and
> {{{}$\{optionals{ which would be used to load additional referenced
> configuration files such as:
> {{ ${optionals} = ${user.home}/.m2/maven.user.properties,
> ${session.rootDirectory}/.mvn/maven.user.properties}}
> Being loaded early when Maven is loaded, those files could reference
> directories to load extensions from:
> {{{}maven.core.extensions.directories =
> ${session.rootDirectory}/.mvn/extensions.xml,{}}}{{{}${user.home}/.m2/extensions.xml,${maven.home}/extensions.xml{}}}
>
> In various places, the maven code could be simplified and offer more
> configuration points at the same time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784978#comment-17784978 ] ASF GitHub Bot commented on MPLUGIN-450: gnodet closed pull request #239: [MPLUGIN-450] Require goalPrefix to be valid URL: https://github.com/apache/maven-plugin-tools/pull/239 > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-450] Require goalPrefix to be valid [maven-plugin-tools]
gnodet closed pull request #239: [MPLUGIN-450] Require goalPrefix to be valid URL: https://github.com/apache/maven-plugin-tools/pull/239 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2210) Additional class path ordering broken since 3.2.0
[
https://issues.apache.org/jira/browse/SUREFIRE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784969#comment-17784969
]
ASF GitHub Bot commented on SUREFIRE-2210:
--
dmlloyd commented on code in PR #686:
URL: https://github.com/apache/maven-surefire/pull/686#discussion_r1389483563
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -2569,7 +2569,7 @@ private TestClassPath generateTestClasspath() throws
MojoFailureException {
Map dependencyConflictIdsProjectArtifacts =
classpathArtifacts.stream()
.collect(Collectors.toMap(Artifact::getDependencyConflictId,
Function.identity()));
-Set additionalClasspathElements = new HashSet<>();
+Set additionalClasspathElements = new LinkedHashSet<>();
Review Comment:
I can find some time to do this next week hopefully.
> Additional class path ordering broken since 3.2.0
> -
>
> Key: SUREFIRE-2210
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2210
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.2
>Reporter: David M. Lloyd
>Priority: Critical
>
> Since commit
> [47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d|https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d]
> ([#667|https://github.com/apache/maven-surefire/pull/667], SUREFIRE-2179),
> the ordering of the {{additionalClasspathElements}} list configuration
> property is no longer preserved. This breaks testing of multi-release JARs,
> where the directories for newer JDKs *must* be strictly ordered *before* the
> directories for older JDKs.
> The problem is likely due to changing the additional class paths collection
> from a `List` to a `Set`, which does not preserve ordering.
> One simple fix could be to change the line {{Set
> additionalClasspathElements = new HashSet<>();}} to construct a
> {{LinkedHashSet}} instead.
> /cc [~kwin] who wrote the original patch back in June.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2210] - Restore ordering of additional class path elements [maven-surefire]
dmlloyd commented on code in PR #686:
URL: https://github.com/apache/maven-surefire/pull/686#discussion_r1389483563
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -2569,7 +2569,7 @@ private TestClassPath generateTestClasspath() throws
MojoFailureException {
Map dependencyConflictIdsProjectArtifacts =
classpathArtifacts.stream()
.collect(Collectors.toMap(Artifact::getDependencyConflictId,
Function.identity()));
-Set additionalClasspathElements = new HashSet<>();
+Set additionalClasspathElements = new LinkedHashSet<>();
Review Comment:
I can find some time to do this next week hopefully.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2210) Additional class path ordering broken since 3.2.0
[
https://issues.apache.org/jira/browse/SUREFIRE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784968#comment-17784968
]
David M. Lloyd commented on SUREFIRE-2210:
--
[~kwin] not easily, unfortunately. At least not this week. I did empirically
verify that the fix does fix our MR JAR build tests, but crafting a test case
will require some thought (especially as I am unfamiliar with the test suite as
it is). Hopefully some existing test can be used as a basis.
> Additional class path ordering broken since 3.2.0
> -
>
> Key: SUREFIRE-2210
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2210
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.2
>Reporter: David M. Lloyd
>Priority: Critical
>
> Since commit
> [47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d|https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d]
> ([#667|https://github.com/apache/maven-surefire/pull/667], SUREFIRE-2179),
> the ordering of the {{additionalClasspathElements}} list configuration
> property is no longer preserved. This breaks testing of multi-release JARs,
> where the directories for newer JDKs *must* be strictly ordered *before* the
> directories for older JDKs.
> The problem is likely due to changing the additional class paths collection
> from a `List` to a `Set`, which does not preserve ordering.
> One simple fix could be to change the line {{Set
> additionalClasspathElements = new HashSet<>();}} to construct a
> {{LinkedHashSet}} instead.
> /cc [~kwin] who wrote the original patch back in June.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2210) Additional class path ordering broken since 3.2.0
[
https://issues.apache.org/jira/browse/SUREFIRE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784965#comment-17784965
]
ASF GitHub Bot commented on SUREFIRE-2210:
--
dmlloyd opened a new pull request, #686:
URL: https://github.com/apache/maven-surefire/pull/686
Following this checklist to help us incorporate your
contribution quickly and easily:
- [X] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/SUREFIRE) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line
and body.
- [X] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `SUREFIRE-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [X] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [X] Run `mvn clean install` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [X] You have run the integration tests successfully (`mvn -Prun-its clean
install`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [X] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
--
The recent change (47eb1974ef2fb, since 3.2.0) to support more additional
class path items during test has broken the use case of testing multi-release
projects where ordering of class path elements is significant by changing the
additional class path items collection from a `List` to a `HashSet`, which has
unreliable ordering semantics. This simple fix preserves the original class
path order specified in the POM by using a `LinkedHashSet`, which preserves
insertion order, instead of a `HashSet`, which does not.
/cc @kwin
> Additional class path ordering broken since 3.2.0
> -
>
> Key: SUREFIRE-2210
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2210
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.2
>Reporter: David M. Lloyd
>Priority: Critical
>
> Since commit
> [47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d|https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d]
> ([#667|https://github.com/apache/maven-surefire/pull/667], SUREFIRE-2179),
> the ordering of the {{additionalClasspathElements}} list configuration
> property is no longer preserved. This breaks testing of multi-release JARs,
> where the directories for newer JDKs *must* be strictly ordered *before* the
> directories for older JDKs.
> The problem is likely due to changing the additional class paths collection
> from a `List` to a `Set`, which does not preserve ordering.
> One simple fix could be to change the line {{Set
> additionalClasspathElements = new HashSet<>();}} to construct a
> {{LinkedHashSet}} instead.
> /cc [~kwin] who wrote the original patch back in June.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [SUREFIRE-2210] - Restore ordering of additional class path elements [maven-surefire]
dmlloyd opened a new pull request, #686: URL: https://github.com/apache/maven-surefire/pull/686 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) -- The recent change (47eb1974ef2fb, since 3.2.0) to support more additional class path items during test has broken the use case of testing multi-release projects where ordering of class path elements is significant by changing the additional class path items collection from a `List` to a `HashSet`, which has unreliable ordering semantics. This simple fix preserves the original class path order specified in the POM by using a `LinkedHashSet`, which preserves insertion order, instead of a `HashSet`, which does not. /cc @kwin -- 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] (SUREFIRE-2210) Additional class path ordering broken since 3.2.0
David M. Lloyd created SUREFIRE-2210:
Summary: Additional class path ordering broken since 3.2.0
Key: SUREFIRE-2210
URL: https://issues.apache.org/jira/browse/SUREFIRE-2210
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.2.2, 3.2.1
Reporter: David M. Lloyd
Since commit
[47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d|https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d]
([#667|https://github.com/apache/maven-surefire/pull/667], SUREFIRE-2179), the
ordering of the {{additionalClasspathElements}} list configuration property is
no longer preserved. This breaks testing of multi-release JARs, where the
directories for newer JDKs *must* be strictly ordered *before* the directories
for older JDKs.
The problem is likely due to changing the additional class paths collection
from a `List` to a `Set`, which does not preserve ordering.
One simple fix could be to change the line {{Set
additionalClasspathElements = new HashSet<>();}} to construct a
{{LinkedHashSet}} instead.
/cc [~kwin] who wrote the original patch back in June.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784939#comment-17784939 ] ASF GitHub Bot commented on MPLUGIN-450: gnodet opened a new pull request, #239: URL: https://github.com/apache/maven-plugin-tools/pull/239 (no comment) > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Automatically format and sort imports according to the new maven coding style [maven-resolver]
cstamas commented on PR #147: URL: https://github.com/apache/maven-resolver/pull/147#issuecomment-1805668706 Parent POM already provides this -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Automatically format and sort imports according to the new maven coding style [maven-resolver]
cstamas closed pull request #147: Automatically format and sort imports according to the new maven coding style URL: https://github.com/apache/maven-resolver/pull/147 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-157) Get rid of ServiceLocator in Resolver
[ https://issues.apache.org/jira/browse/MRESOLVER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784923#comment-17784923 ] ASF GitHub Bot commented on MRESOLVER-157: -- cstamas closed pull request #88: [MRESOLVER-157] Drop ServiceLocator URL: https://github.com/apache/maven-resolver/pull/88 > Get rid of ServiceLocator in Resolver > - > > Key: MRESOLVER-157 > URL: https://issues.apache.org/jira/browse/MRESOLVER-157 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-1 > > > maven-resolver currently supports: > * ServiceLocator (deprecated as of 1.7.0 see MRESOLVER-160) > * "vanilla" Guice (provides a module) > * DI using Sisu, as used in Maven > IMO, it makes not much sense to support 3 vastly different "DI"s (in quotes > as ServiceLocator is really just a dumb factory pattern). > Not only just complicates the code base, makes changes error prone at least, > yields for "exceptions" (this or that will never work with it, as seen with > SyncContext), and, for me most importantly, prevents proper constructor > initialization and validation of components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-157) Get rid of ServiceLocator in Resolver
[ https://issues.apache.org/jira/browse/MRESOLVER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784922#comment-17784922 ] ASF GitHub Bot commented on MRESOLVER-157: -- cstamas commented on PR #88: URL: https://github.com/apache/maven-resolver/pull/88#issuecomment-1805667484 Superseded by https://github.com/apache/maven-resolver/pull/340 > Get rid of ServiceLocator in Resolver > - > > Key: MRESOLVER-157 > URL: https://issues.apache.org/jira/browse/MRESOLVER-157 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-1 > > > maven-resolver currently supports: > * ServiceLocator (deprecated as of 1.7.0 see MRESOLVER-160) > * "vanilla" Guice (provides a module) > * DI using Sisu, as used in Maven > IMO, it makes not much sense to support 3 vastly different "DI"s (in quotes > as ServiceLocator is really just a dumb factory pattern). > Not only just complicates the code base, makes changes error prone at least, > yields for "exceptions" (this or that will never work with it, as seen with > SyncContext), and, for me most importantly, prevents proper constructor > initialization and validation of components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-157] Drop ServiceLocator [maven-resolver]
cstamas closed pull request #88: [MRESOLVER-157] Drop ServiceLocator URL: https://github.com/apache/maven-resolver/pull/88 -- 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] [MRESOLVER-157] Drop ServiceLocator [maven-resolver]
cstamas commented on PR #88: URL: https://github.com/apache/maven-resolver/pull/88#issuecomment-1805667484 Superseded by https://github.com/apache/maven-resolver/pull/340 -- 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] refactor: refactor bad smell ProtectedMemberInFinalClass [maven-resolver]
cstamas closed pull request #305: refactor: refactor bad smell ProtectedMemberInFinalClass URL: https://github.com/apache/maven-resolver/pull/305 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MRESOLVER-431) Make chained repository and transport listeners extensible
[
https://issues.apache.org/jira/browse/MRESOLVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-431.
-
Resolution: Fixed
> Make chained repository and transport listeners extensible
> --
>
> Key: MRESOLVER-431
> URL: https://issues.apache.org/jira/browse/MRESOLVER-431
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> These two classes seems unfinished in multiple ways:
> * both are {{final}}, so cannot be extended
> * there is some "intent" for error handling, but is protected method (but
> class is final)
> * empty method requires extra signaling toward checkstyle
> So, rather just make them extensible (non-final).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] refactor: refactor bad smell ProtectedMemberInFinalClass [maven-resolver]
cstamas commented on PR #305: URL: https://github.com/apache/maven-resolver/pull/305#issuecomment-1805665464 Fixed as https://issues.apache.org/jira/browse/MRESOLVER-431 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-431) Make chained repository and transport listeners extensible
[
https://issues.apache.org/jira/browse/MRESOLVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784920#comment-17784920
]
ASF GitHub Bot commented on MRESOLVER-431:
--
cstamas merged PR #361:
URL: https://github.com/apache/maven-resolver/pull/361
> Make chained repository and transport listeners extensible
> --
>
> Key: MRESOLVER-431
> URL: https://issues.apache.org/jira/browse/MRESOLVER-431
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> These two classes seems unfinished in multiple ways:
> * both are {{final}}, so cannot be extended
> * there is some "intent" for error handling, but is protected method (but
> class is final)
> * empty method requires extra signaling toward checkstyle
> So, rather just make them extensible (non-final).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-431) Make chained repository and transport listeners extensible
[
https://issues.apache.org/jira/browse/MRESOLVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-431:
--
Description:
These two classes seems unfinished in multiple ways:
* both are {{final}}, so cannot be extended
* there is some "intent" for error handling, but is protected method (but class
is final)
* empty method requires extra signaling toward checkstyle
So, rather just make them extensible (non-final).
was:
These two classes seems unfinished in multiple ways:
* both are {{final}}, so cannot be extended
* there is some "intent" for error handling, but is protected method (but class
is final)
* empty method requires extra signaling toward checkstyle
So, rather:
* introduce "error handler" ability, at least ability to gather errors
* make the questionable method private on final class, as expected
> Make chained repository and transport listeners extensible
> --
>
> Key: MRESOLVER-431
> URL: https://issues.apache.org/jira/browse/MRESOLVER-431
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> These two classes seems unfinished in multiple ways:
> * both are {{final}}, so cannot be extended
> * there is some "intent" for error handling, but is protected method (but
> class is final)
> * empty method requires extra signaling toward checkstyle
> So, rather just make them extensible (non-final).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-431] Make chained repository and transfer listeners extensible [maven-resolver]
cstamas merged PR #361: URL: https://github.com/apache/maven-resolver/pull/361 -- 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] (MRESOLVER-431) Make chained repository and transport listeners extensible
[
https://issues.apache.org/jira/browse/MRESOLVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-431:
--
Summary: Make chained repository and transport listeners extensible (was:
Chained repository and transport listeners improvement)
> Make chained repository and transport listeners extensible
> --
>
> Key: MRESOLVER-431
> URL: https://issues.apache.org/jira/browse/MRESOLVER-431
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> These two classes seems unfinished in multiple ways:
> * both are {{final}}, so cannot be extended
> * there is some "intent" for error handling, but is protected method (but
> class is final)
> * empty method requires extra signaling toward checkstyle
> So, rather:
> * introduce "error handler" ability, at least ability to gather errors
> * make the questionable method private on final class, as expected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-431) Chained repository and transport listeners improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MRESOLVER-431:
-
Assignee: Tamas Cservenak
> Chained repository and transport listeners improvement
> --
>
> Key: MRESOLVER-431
> URL: https://issues.apache.org/jira/browse/MRESOLVER-431
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> These two classes seems unfinished in multiple ways:
> * both are {{final}}, so cannot be extended
> * there is some "intent" for error handling, but is protected method (but
> class is final)
> * empty method requires extra signaling toward checkstyle
> So, rather:
> * introduce "error handler" ability, at least ability to gather errors
> * make the questionable method private on final class, as expected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-431) Chained repository and transport listeners improvement
[
https://issues.apache.org/jira/browse/MRESOLVER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784907#comment-17784907
]
ASF GitHub Bot commented on MRESOLVER-431:
--
cstamas opened a new pull request, #361:
URL: https://github.com/apache/maven-resolver/pull/361
Add ability to process errors, that were impossible currently. Also, sort
out a strange case of `protected` method on a `final` class.
---
https://issues.apache.org/jira/browse/MRESOLVER-431
> Chained repository and transport listeners improvement
> --
>
> Key: MRESOLVER-431
> URL: https://issues.apache.org/jira/browse/MRESOLVER-431
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> These two classes seems unfinished in multiple ways:
> * both are {{final}}, so cannot be extended
> * there is some "intent" for error handling, but is protected method (but
> class is final)
> * empty method requires extra signaling toward checkstyle
> So, rather:
> * introduce "error handler" ability, at least ability to gather errors
> * make the questionable method private on final class, as expected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-431) Chained repository and transport listeners improvement
Tamas Cservenak created MRESOLVER-431:
-
Summary: Chained repository and transport listeners improvement
Key: MRESOLVER-431
URL: https://issues.apache.org/jira/browse/MRESOLVER-431
Project: Maven Resolver
Issue Type: Task
Components: Resolver
Reporter: Tamas Cservenak
Fix For: 2.0.0
These two classes seems unfinished in multiple ways:
* both are {{final}}, so cannot be extended
* there is some "intent" for error handling, but is protected method (but class
is final)
* empty method requires extra signaling toward checkstyle
So, rather:
* introduce "error handler" ability, at least ability to gather errors
* make the questionable method private on final class, as expected
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MCOMPILER-549) improve recompilation cause display
[ https://issues.apache.org/jira/browse/MCOMPILER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MCOMPILER-549. - > improve recompilation cause display > --- > > Key: MCOMPILER-549 > URL: https://issues.apache.org/jira/browse/MCOMPILER-549 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Maarten Mulders >Priority: Major > Fix For: 3.12.0 > > > recompilation cause message has been implemented in MCOMPILER-499 > But message format is strange and some values are not clear: see last comment > in MCOMPILER-499 and users feedback > https://lists.apache.org/thread/on96m5fkngm43tppr67hxrjmk3wy2s79 > we need to improve the message a little bit -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-554) Update plexus-java to 1.2.0
[ https://issues.apache.org/jira/browse/MCOMPILER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MCOMPILER-554. - Fix Version/s: 3.12.0 Assignee: Slawomir Jaranowski Resolution: Fixed > Update plexus-java to 1.2.0 > --- > > Key: MCOMPILER-554 > URL: https://issues.apache.org/jira/browse/MCOMPILER-554 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.11.0 >Reporter: Jorge Solórzano >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.12.0 > > > This also bumps ASM to 9.6 supporting Java 21. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-550) Make 'outputDirectory' writable
[
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MCOMPILER-550.
-
> Make 'outputDirectory' writable
> ---
>
> Key: MCOMPILER-550
> URL: https://issues.apache.org/jira/browse/MCOMPILER-550
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.12.0
>
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writable, i.e. not meant to
> be modified.
> However, making it writable has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars)
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only
> be controlled by setting the {{release}} property. That will not only require
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
> Java 24. Here is an example use case:
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For
> example, the SecurityManager is not just deprecated, it is deprecated for
> removal. The moment we know which Java version it is, we can create a MR-Jar
> for e.g. Java 30, even though Java 30 SDKs are not available then (currently
> we have Java 21 GA).
> h2. Proposed solution
> Make variable writable as suggested in Slack.
> PR available locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-554) Update plexus-java to 1.2.0
[ https://issues.apache.org/jira/browse/MCOMPILER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784774#comment-17784774 ] ASF GitHub Bot commented on MCOMPILER-554: -- slawekjaranowski merged PR #207: URL: https://github.com/apache/maven-compiler-plugin/pull/207 > Update plexus-java to 1.2.0 > --- > > Key: MCOMPILER-554 > URL: https://issues.apache.org/jira/browse/MCOMPILER-554 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.11.0 >Reporter: Jorge Solórzano >Priority: Major > > This also bumps ASM to 9.6 supporting Java 21. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-554] Update plexus-java to 1.2.0 [maven-compiler-plugin]
slawekjaranowski merged PR #207: URL: https://github.com/apache/maven-compiler-plugin/pull/207 -- 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-554) Update plexus-java to 1.2.0
[ https://issues.apache.org/jira/browse/MCOMPILER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Solórzano updated MCOMPILER-554: -- Flags: Patch > Update plexus-java to 1.2.0 > --- > > Key: MCOMPILER-554 > URL: https://issues.apache.org/jira/browse/MCOMPILER-554 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.11.0 >Reporter: Jorge Solórzano >Priority: Major > > This also bumps ASM to 9.6 supporting Java 21. -- This message was sent by Atlassian Jira (v8.20.10#820010)
