[jira] [Comment Edited] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794894#comment-17794894
]
Olivier Lamy edited comment on MBUILDCACHE-73 at 12/9/23 12:56 AM:
---
simply skip test during release:prepare or perform or even both (as your build
has already been validated by a CI?)
regarding your line 1.1-SNAPSHOT, regular build , cache with version Full
Build. Really?? I guess only once after version change or any source change
was (Author: olamy):
simply skip test during release:prepare or perform or even both.
regarding your line 1.1-SNAPSHOT, regular build , cache with version Full
Build. Really?? I guess only once after version change or any source change
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794894#comment-17794894
]
Olivier Lamy commented on MBUILDCACHE-73:
-
simply skip test during release:prepare or perform or even both.
regarding your line 1.1-SNAPSHOT, regular build , cache with version Full
Build. Really?? I guess only once after version change or any source change
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [SUREFIRE-2220] SurefireForkChannel#getForkNodeConnectionString() ret… [maven-surefire]
michael-o opened a new pull request, #697: URL: https://github.com/apache/maven-surefire/pull/697 …urns invalid URI string if localHost resolves to IPv6 address This closes #697 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/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. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] 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. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] 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. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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] (SUREFIRE-2220) SurefireForkChannel#getForkNodeConnectionString() returns invalid URI string if localHost resolves to IPv6 address
[
https://issues.apache.org/jira/browse/SUREFIRE-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-2220:
-
Summary: SurefireForkChannel#getForkNodeConnectionString() returns invalid
URI string if localHost resolves to IPv6 address (was:
SurefireForkChannel.getForkNodeConnectionString returning invalid URI String if
localHost resolves to IPv6 address literal)
> SurefireForkChannel#getForkNodeConnectionString() returns invalid URI string
> if localHost resolves to IPv6 address
> --
>
> Key: SUREFIRE-2220
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2220
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.2.2
>Reporter: Lutz Neugebauer
>Priority: Major
>
> [SurefireForkChannel.getForkNodeConnectionString|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L114]
> returns invalid URI string if localhost is an IPv6 address literal:
> {code:java}
> public String getForkNodeConnectionString() {
> return "tcp://" + localHost + ":" + localPort + (isBlank(sessionId) ?
> "" : "?sessionId=" + sessionId);
> } {code}
> localHost is initialized from
> [InetSocketAddress.getHostString()|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/InetSocketAddress.html#getHostString()]
> at
> [SurefireForkChannel.SurefireForkChannel()|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L100]
> which may return "... the String form of the address if it doesn't have a
> hostname (it was created using a literal)."
> If an IPv6 address is returned, then the URI computed is something like
> {code:java}
> tcp://0:0:0:0:0:0:0:1:34398?sessionId=... {code}
> instead of required format (cf.
> [URI.URI()|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/URI.html#%3Cinit%3E(java.lang.String])
> {code:java}
> tcp://[0:0:0:0:0:0:0:1]:34398?sessionId=... {code}
> At my end the incorrect URI seems to cause hanging build, probably when it is
> consumed at
> [SurefireMasterProcessChannelProcessorFactory.connect()|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/surefire-booter/src/main/java/org/apache/maven/surefire/booter/spi/SurefireMasterProcessChannelProcessorFactory.java#L74].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2220) SurefireForkChannel#getForkNodeConnectionString() returns invalid URI string if localHost resolves to IPv6 address
[
https://issues.apache.org/jira/browse/SUREFIRE-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794880#comment-17794880
]
ASF GitHub Bot commented on SUREFIRE-2220:
--
michael-o opened a new pull request, #697:
URL: https://github.com/apache/maven-surefire/pull/697
…urns invalid URI string if localHost resolves to IPv6 address
This closes #697
Following this checklist to help us incorporate your
contribution quickly and easily:
- [ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/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.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] 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.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean install` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] 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.
- [ ] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> SurefireForkChannel#getForkNodeConnectionString() returns invalid URI string
> if localHost resolves to IPv6 address
> --
>
> Key: SUREFIRE-2220
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2220
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.2.2
>Reporter: Lutz Neugebauer
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> [SurefireForkChannel.getForkNodeConnectionString|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L114]
> returns invalid URI string if localhost is an IPv6 address literal:
> {code:java}
> public String getForkNodeConnectionString() {
> return "tcp://" + localHost + ":" + localPort + (isBlank(sessionId) ?
> "" : "?sessionId=" + sessionId);
> } {code}
> localHost is initialized from
> [InetSocketAddress.getHostString()|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/InetSocketAddress.html#getHostString()]
> at
> [SurefireForkChannel.SurefireForkChannel()|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L100]
> which may return "... the String form of the address if it doesn't have a
> hostname (it was created using a literal)."
> If an IPv6 address is returned, then the URI computed is something like
> {code:java}
> tcp://0:0:0:0:0:0:0:1:34398?sessionId=... {code}
> instead of required format (cf.
> [URI.URI()|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/URI.html#%3Cinit%3E(java.lang.String])
> {code:java}
> tcp://[0:0:0:0:0:0:0:1]:34398?sessionId=... {code}
> At my end the incorrect URI seems to cause hanging build, probably when it is
> consumed at
> [SurefireMasterProcessChannelProcessorFactory.connect()|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/surefire-booter/src/main/java/org/apache/maven/surefire/booter/spi/SurefireMasterProcessChannelProcessorFactory.java#L74].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2220) SurefireForkChannel#getForkNodeConnectionString() returns invalid URI string if localHost resolves to IPv6 address
[
https://issues.apache.org/jira/browse/SUREFIRE-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-2220:
-
Fix Version/s: 3.2.3
> SurefireForkChannel#getForkNodeConnectionString() returns invalid URI string
> if localHost resolves to IPv6 address
> --
>
> Key: SUREFIRE-2220
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2220
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.2.2
>Reporter: Lutz Neugebauer
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> [SurefireForkChannel.getForkNodeConnectionString|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L114]
> returns invalid URI string if localhost is an IPv6 address literal:
> {code:java}
> public String getForkNodeConnectionString() {
> return "tcp://" + localHost + ":" + localPort + (isBlank(sessionId) ?
> "" : "?sessionId=" + sessionId);
> } {code}
> localHost is initialized from
> [InetSocketAddress.getHostString()|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/InetSocketAddress.html#getHostString()]
> at
> [SurefireForkChannel.SurefireForkChannel()|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L100]
> which may return "... the String form of the address if it doesn't have a
> hostname (it was created using a literal)."
> If an IPv6 address is returned, then the URI computed is something like
> {code:java}
> tcp://0:0:0:0:0:0:0:1:34398?sessionId=... {code}
> instead of required format (cf.
> [URI.URI()|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/URI.html#%3Cinit%3E(java.lang.String])
> {code:java}
> tcp://[0:0:0:0:0:0:0:1]:34398?sessionId=... {code}
> At my end the incorrect URI seems to cause hanging build, probably when it is
> consumed at
> [SurefireMasterProcessChannelProcessorFactory.connect()|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/surefire-booter/src/main/java/org/apache/maven/surefire/booter/spi/SurefireMasterProcessChannelProcessorFactory.java#L74].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-2220) SurefireForkChannel#getForkNodeConnectionString() returns invalid URI string if localHost resolves to IPv6 address
[
https://issues.apache.org/jira/browse/SUREFIRE-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned SUREFIRE-2220:
Assignee: Michael Osipov
> SurefireForkChannel#getForkNodeConnectionString() returns invalid URI string
> if localHost resolves to IPv6 address
> --
>
> Key: SUREFIRE-2220
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2220
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.2.2
>Reporter: Lutz Neugebauer
>Assignee: Michael Osipov
>Priority: Major
>
> [SurefireForkChannel.getForkNodeConnectionString|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L114]
> returns invalid URI string if localhost is an IPv6 address literal:
> {code:java}
> public String getForkNodeConnectionString() {
> return "tcp://" + localHost + ":" + localPort + (isBlank(sessionId) ?
> "" : "?sessionId=" + sessionId);
> } {code}
> localHost is initialized from
> [InetSocketAddress.getHostString()|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/InetSocketAddress.html#getHostString()]
> at
> [SurefireForkChannel.SurefireForkChannel()|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/extensions/SurefireForkChannel.java#L100]
> which may return "... the String form of the address if it doesn't have a
> hostname (it was created using a literal)."
> If an IPv6 address is returned, then the URI computed is something like
> {code:java}
> tcp://0:0:0:0:0:0:0:1:34398?sessionId=... {code}
> instead of required format (cf.
> [URI.URI()|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/URI.html#%3Cinit%3E(java.lang.String])
> {code:java}
> tcp://[0:0:0:0:0:0:0:1]:34398?sessionId=... {code}
> At my end the incorrect URI seems to cause hanging build, probably when it is
> consumed at
> [SurefireMasterProcessChannelProcessorFactory.connect()|https://github.com/apache/maven-surefire/blob/2d7675397e884b18d59a596c004e73982368ee7c/surefire-booter/src/main/java/org/apache/maven/surefire/booter/spi/SurefireMasterProcessChannelProcessorFactory.java#L74].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1341) Convert tests to Junit 5
[ https://issues.apache.org/jira/browse/MSHARED-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794878#comment-17794878 ] ASF GitHub Bot commented on MSHARED-1341: - slachiewicz opened a new pull request, #89: URL: https://github.com/apache/maven-filtering/pull/89 (no comment) > Convert tests to Junit 5 > > > Key: MSHARED-1341 > URL: https://issues.apache.org/jira/browse/MSHARED-1341 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-filtering-3.3.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MSHARED-1341] Convert tests to Junit 5 [maven-filtering]
slachiewicz opened a new pull request, #89: URL: https://github.com/apache/maven-filtering/pull/89 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-545) maven.compiler.target seem to be ignored
[
https://issues.apache.org/jira/browse/MCOMPILER-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794864#comment-17794864
]
Jorge Solórzano commented on MCOMPILER-545:
---
Not sure what are you expecting, could you please explain better what is the
issue? Are you setting the target to 1.8, building with JDK 11 and expect that
the major version is 55?
If I change the maven.compiler.target property to 1.8, to 11, to 17, etc, the
major version match the expected output.
* JDK 8 => major version: 52
* JDK 11 => major version: 55
* JDK 17 => major version: 61
> maven.compiler.target seem to be ignored
>
>
> Key: MCOMPILER-545
> URL: https://issues.apache.org/jira/browse/MCOMPILER-545
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: Mihai Nita
>Priority: Major
>
> Create a very simple maven project:
> {code:java}
> mvn archetype:generate \
> -DgroupId=com.mycompany.app \
> -DartifactId=my-app \
> -DarchetypeArtifactId=maven-archetype-quickstart \
> -DarchetypeVersion=1.4 \
> -DinteractiveMode=false{code}
> See the guide at "Maven in 5 Minutes"
> [https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html]
>
> Change folder:
> {code:java}
> cd my-app {code}
> Edit the `pom.xml` and change the JDK version to 8 (the newly created project
> uses 7):
> {code:java}
> 1.8
> 1.8 {code}
> Compile:
> {code:java}
> mvn clean compile {code}
> Check the version of the class file generated:
> {code:java}
> javap -v target/classes/com/mycompany/app/App.class | grep "major
> version"{code}
> If you compile with various jdk versions you will get different results: *
> JDK 8 => major version: 52
> * JDK 11 => major version: 55
> * JDK 17 => major version: 61
> So this is not work as one would expect (and as documented).
> It looks like a bug in the {{{}maven-compiler-plugin{}}}.
>
> The behavior is the same even if we update the plugin to latest version
> (3.11.0).
> (the app generated by the archetype uses 3.8.0, so the bug is not new)
> Or if we use `8` for the version (instead of `1.8`).
> [https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html]
>
> Changing the version *works* if specified in the plugin using
> {{}} in {{{}{}}}.
> [https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html]
>
> This show that {{maven.compiler.target}} does not work.
> I suspect (but didn't test) that is also true for {{maven.compiler.source}}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCOMPILER-564) Update plexus-compiler to 2.14.0
Jorge Solórzano created MCOMPILER-564: - Summary: Update plexus-compiler to 2.14.0 Key: MCOMPILER-564 URL: https://issues.apache.org/jira/browse/MCOMPILER-564 Project: Maven Compiler Plugin Issue Type: Dependency upgrade Affects Versions: 3.11.0 Reporter: Jorge Solórzano Once the plexus-compiler release is done to 2.14.0, it should be updated in maven-compier-plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCOMPILER-563) Deprecate/rename useIncrementalCompilation
[ https://issues.apache.org/jira/browse/MCOMPILER-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Solórzano updated MCOMPILER-563: -- Issue Type: Task (was: Improvement) > Deprecate/rename useIncrementalCompilation > -- > > Key: MCOMPILER-563 > URL: https://issues.apache.org/jira/browse/MCOMPILER-563 > Project: Maven Compiler Plugin > Issue Type: Task >Reporter: Jorge Solórzano >Priority: Major > > The property *maven.compiler.useIncrementalCompilation* has the unfortunate > name that makes it believe that Maven is using "incremental" source code > compilation. > People always believe that this compiles only the single class or source code > that has changed when the reality is that it only is used to detect changes > and recompile the full Maven project/module. > The proposal would be to deprecate this property now and rename it in the 4.0 > branch to something like *maven.compiler.rebuildDetection.* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCOMPILER-563) Deprecate/rename useIncrementalCompilation
[ https://issues.apache.org/jira/browse/MCOMPILER-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Solórzano updated MCOMPILER-563: -- Affects Version/s: 3.11.0 > Deprecate/rename useIncrementalCompilation > -- > > Key: MCOMPILER-563 > URL: https://issues.apache.org/jira/browse/MCOMPILER-563 > Project: Maven Compiler Plugin > Issue Type: Task >Affects Versions: 3.11.0 >Reporter: Jorge Solórzano >Priority: Major > > The property *maven.compiler.useIncrementalCompilation* has the unfortunate > name that makes it believe that Maven is using "incremental" source code > compilation. > People always believe that this compiles only the single class or source code > that has changed when the reality is that it only is used to detect changes > and recompile the full Maven project/module. > The proposal would be to deprecate this property now and rename it in the 4.0 > branch to something like *maven.compiler.rebuildDetection.* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-563) Deprecate/rename useIncrementalCompilation
Jorge Solórzano created MCOMPILER-563: - Summary: Deprecate/rename useIncrementalCompilation Key: MCOMPILER-563 URL: https://issues.apache.org/jira/browse/MCOMPILER-563 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: Jorge Solórzano The property *maven.compiler.useIncrementalCompilation* has the unfortunate name that makes it believe that Maven is using "incremental" source code compilation. People always believe that this compiles only the single class or source code that has changed when the reality is that it only is used to detect changes and recompile the full Maven project/module. The proposal would be to deprecate this property now and rename it in the 4.0 branch to something like *maven.compiler.rebuildDetection.* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Fix Maven 3.9.6 announce link in history page [maven-site]
cstamas opened a new pull request, #475: URL: https://github.com/apache/maven-site/pull/475 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Prepare 4.0.0-alpha-9 [maven-site]
cstamas commented on code in PR #474: URL: https://github.com/apache/maven-site/pull/474#discussion_r1420979846 ## content/markdown/docs/4.0.0-alpha-9/release-notes.md: ## @@ -0,0 +1,63 @@ + + +# Release Notes Maven 4.0.0-alpha-9 + +The Apache Maven team would like to announce the release of Maven 4.0.0-alpha-9. + +This is alpha release, not suitable for production. + +Maven 4.0.0-alpha-9 is [available for download][0]. + +Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting, and documentation from a central place. + +The core release is independent of plugin releases. Further releases of plugins will be made separately. See the [PluginList][1] for more information. + +If you have any questions, please consult: + +- the web site: [https://maven.apache.org/][2] +- the maven-user mailing list: [https://maven.apache.org/mailing-lists.html](/mailing-lists.html) +- the reference documentation: [https://maven.apache.org/ref/4.0.0-alpha-9/](/ref/4.0.0-alpha-9/) + +## Overview About the Changes + +The full list of changes can be found in our [issue management system][4]. Among those are: + - switch to Maven Resolver 2.0.0-alpha-3 + - multi-threaded model builder + - namespace support in xml configuration + - ability to create proxies to inject SessionScoped beans into singletons + - Maven 4 API improvements: plugin api, dependency collection / resolution, version / version range resolution + +## Known Issues + +If you find any incompatibility with latest versions of plugins, do not hesitate to report those. + +## Complete Release Notes + +See [complete release notes for all versions][5] + +[0]: https://dlcdn.apache.org/maven/maven-4/4.0.0-alpha-9/ +[1]: ../../plugins/index.html +[2]: https://maven.apache.org/ +[4]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353356 Review Comment: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353746 -- 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] Prepare 4.0.0-alpha-9 [maven-site]
gnodet opened a new pull request, #474: URL: https://github.com/apache/maven-site/pull/474 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794828#comment-17794828 ] Tamas Cservenak edited comment on MRESOLVER-391 at 12/8/23 6:32 PM: If nothing to be added here, I am about to move this issue out of resolver 2.0.0, since as I explained above, I think "resolver is fine", what users see are pesky bugs spread across Maven and (mostly) Maven plugins. Regarding "what should be done with this issue to resolve it"... well, again, I think those pesky bugs should be fixed, since what I saw and hear from you, resolver is able to deliver what you need, under the condition to not have wrong expectations (like "test" classpath is superset of "runtime" classpath). As violation of this (in enforcer, assembly, dependency plugins) causes actually all the issues i see so far. was (Author: cstamas): If nothing to be added here, I am about to move this issue out of resolver 2.0.0, since as I explained above, I think "resolver is fine", what users see are pesky bugs spread across Maven and (mostly) Maven plugins. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794828#comment-17794828 ] Tamas Cservenak commented on MRESOLVER-391: --- If nothing to be added here, I am about to move this issue out of resolver 2.0.0, since as I explained above, I think "resolver is fine", what users see are pesky bugs spread across Maven and (mostly) Maven plugins. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Prepare for alpha-9 [maven-resolver]
cstamas opened a new pull request, #393: URL: https://github.com/apache/maven-resolver/pull/393 Seems old plexus and stuff creeps in via plexus-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] (MRESOLVER-335) Better resolver errors for Artifact Not Found
[
https://issues.apache.org/jira/browse/MRESOLVER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794813#comment-17794813
]
ASF GitHub Bot commented on MRESOLVER-335:
--
cstamas commented on PR #386:
URL: https://github.com/apache/maven-resolver/pull/386#issuecomment-1847563980
One thing am unsure about: `Map exceptions`
in ArtifactResult... I think it should be `Map> exceptions` instead...
> Better resolver errors for Artifact Not Found
> -
>
> Key: MRESOLVER-335
> URL: https://issues.apache.org/jira/browse/MRESOLVER-335
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: 2.0.0
>
>
> When we have many remote repositories only first
> {{ArtifactNotFoundException}} is returned, all checks for other repositories
> are hidden.
> When we have errors for many artifacts in one request - list of problematic
> artifacts is present in message and only first exception for one artifact.
> Next case is with remote repository filtering, checks for remote repository
> according to filtering also produce {{ArtifactNotFoundException}}, this is
> done at the beginning so exception is first on list.
> In logs and exception we have:
> {code}
> Downloading from my-mirror:
> https://artifactory.../artifactory/remote-repos/org/apache/commons/commons-lang3/4.4.4/commons-lang3-4.4.4.pom
> [WARNING] The POM for org.apache.commons:commons-lang3:jar:4.4.4 is missing,
> no dependency information available
> Downloading from my-mirror:
> https://artifactory.../artifactory/remote-repos/org/apache/commons/commons-lang3/4.4.4/commons-lang3-4.4.4.jar
> [ERROR] Failed to execute goal on project maven-3.9: Could not resolve
> dependencies for project org.test:maven-3.9:jar:1.0.0-SNAPSHOT: Prefix org
> NOT allowed from mayrepo (https://artifactory.../artifactory/myrepo/,
> default, releases+snapshots)
> {code}
> As we see artefact was not found in {{my-mirror}}, but in error report we
> have information about not allowed prefixes - it can be confusing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-335] Proposal for better errors [maven-resolver]
cstamas commented on PR #386: URL: https://github.com/apache/maven-resolver/pull/386#issuecomment-1847563980 One thing am unsure about: `Map exceptions` in ArtifactResult... I think it should be `Map> exceptions` 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] [Assigned] (MRESOLVER-450) Add a RepositoryCache#computeIfAbsent method
[ https://issues.apache.org/jira/browse/MRESOLVER-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-450: - Assignee: Tamas Cservenak > Add a RepositoryCache#computeIfAbsent method > > > Key: MRESOLVER-450 > URL: https://issues.apache.org/jira/browse/MRESOLVER-450 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Similar to MRESOLVER-204, improvement for RepositoryCache -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-449) Make HTTP transports use common test and server
[ https://issues.apache.org/jira/browse/MRESOLVER-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-449: - Assignee: Tamas Cservenak > Make HTTP transports use common test and server > --- > > Key: MRESOLVER-449 > URL: https://issues.apache.org/jira/browse/MRESOLVER-449 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > This is somewhat related to MRESOLVER-417, but for start is only about to > introduce some common set of test tooling for HTTP transports. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-449) Make HTTP transports use common test and server
[ https://issues.apache.org/jira/browse/MRESOLVER-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794808#comment-17794808 ] ASF GitHub Bot commented on MRESOLVER-449: -- cstamas commented on PR #391: URL: https://github.com/apache/maven-resolver/pull/391#issuecomment-1847529880 I am about to merge this PR as: * it covers all HTTP transports with tests * contains substantial bug fixes in two new transports * disables the failing tests for now We can always reiterate on this, IMHO the bug fixes are important (and should go into alpha-4) > Make HTTP transports use common test and server > --- > > Key: MRESOLVER-449 > URL: https://issues.apache.org/jira/browse/MRESOLVER-449 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > This is somewhat related to MRESOLVER-417, but for start is only about to > introduce some common set of test tooling for HTTP transports. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-449] Step toward testing all HTTP transports [maven-resolver]
cstamas commented on PR #391: URL: https://github.com/apache/maven-resolver/pull/391#issuecomment-1847529880 I am about to merge this PR as: * it covers all HTTP transports with tests * contains substantial bug fixes in two new transports * disables the failing tests for now We can always reiterate on this, IMHO the bug fixes are important (and should go into alpha-4) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7928) Upgrade JUnit Jupiter Version 5.10.1
[ https://issues.apache.org/jira/browse/MNG-7928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7928: - Issue Type: Dependency upgrade (was: Improvement) > Upgrade JUnit Jupiter Version 5.10.1 > > > Key: MNG-7928 > URL: https://issues.apache.org/jira/browse/MNG-7928 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 4.0.0-alpha-8 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.0-alpha-9, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7929) Upgrade Mockito to 5.7.0
[ https://issues.apache.org/jira/browse/MNG-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7929: - Issue Type: Dependency upgrade (was: Improvement) > Upgrade Mockito to 5.7.0 > > > Key: MNG-7929 > URL: https://issues.apache.org/jira/browse/MNG-7929 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 4.0.0-alpha-8 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.0-alpha-9, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7931) Upgrade asm version to 9.6
[ https://issues.apache.org/jira/browse/MNG-7931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7931: - Issue Type: Dependency upgrade (was: Improvement) > Upgrade asm version to 9.6 > -- > > Key: MNG-7931 > URL: https://issues.apache.org/jira/browse/MNG-7931 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 4.0.0-alpha-8 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.0-alpha-9, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7932) Upgrade maven-parent to v41
[ https://issues.apache.org/jira/browse/MNG-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7932: - Issue Type: Dependency upgrade (was: Improvement) > Upgrade maven-parent to v41 > --- > > Key: MNG-7932 > URL: https://issues.apache.org/jira/browse/MNG-7932 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 4.0.0-alpha-8 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.0-alpha-9, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7615) Multithreaded model builder
[ https://issues.apache.org/jira/browse/MNG-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7615: - Issue Type: Improvement (was: Task) > Multithreaded model builder > --- > > Key: MNG-7615 > URL: https://issues.apache.org/jira/browse/MNG-7615 > Project: Maven > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-9 > > > Parsing all reactor models can be very lengthy, so use a map/reduce algorithm > to make the computation in parallel. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7662) Proxy session scoped components so that they can be injected into singletons beans
[
https://issues.apache.org/jira/browse/MNG-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7662:
-
Issue Type: New Feature (was: Bug)
> Proxy session scoped components so that they can be injected into singletons
> beans
> --
>
> Key: MNG-7662
> URL: https://issues.apache.org/jira/browse/MNG-7662
> Project: Maven
> Issue Type: New Feature
>Reporter: Christoph Läubrich
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> The {{SessionScope}} will now create proxies to wrap beans when there's a
> need to inject a bean while the session scope is not yet available. Such
> proxies require the use of a {{Typed}} annotation, either the
> {{org.eclipse.sisu.Typed}} or {{javax.enterprise.inject.Typed}} annotation,
> to be put on the bean that requires to be wrapped by a proxy.
> {code:java}
> @Named
> static class MySingletonBean {
> @Inject
> BeanItf myBean;
> }
> interface BeanItf {
> Session getSession();
> }
> @SessionScoped
> @Typed
> static class MySessionScopedBean implements BeanItf {
> @Inject
> Session session;
> public Session getSession() {
> return session;
> }
> }
> {code}
> ===
> Original problem:
> Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
> at a very early stage. This leads to the problem, that a GraphBuilder
> implementation can not use any SessionScoped Components (because the session
> scope is not setup yet).
> The error then is
> {code:java}
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> while locating org.apache.maven.execution.MavenSession
> for the 1st parameter of
> org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.helper.PluginRealmHelper
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
> at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
> while locating org.eclipse.tycho.build.TychoGraphBuilder
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-6036) Allow proper namespace usage for pom.xml
[
https://issues.apache.org/jira/browse/MNG-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-6036:
-
Issue Type: New Feature (was: Bug)
> Allow proper namespace usage for pom.xml
>
>
> Key: MNG-6036
> URL: https://issues.apache.org/jira/browse/MNG-6036
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_40, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"
>Reporter: Roland Huss
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> When I use the following pom.xml in order to allow an XSD for my custom
> plugin configuration:
> {code:xml}
> http://www.w3.org/2001/XMLSchema-instance;
> xmlns="http://maven.apache.org/POM/4.0.0;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/POM/4.0.0;>
>
>
>
> http://maven.apache.org/POM/4.0.0;
> xmlns="http://fabric8.io/fabric8-maven-plugin;>
> .
>
>
>
>
> {code}
> I get this error:
> {code}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Malformed POM
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml:
> Unrecognised tag: 'm:configuration' (position: START_TAG seen
> ...che.org/POM/4.0.0" xmlns="http://fabric8.io/fabric8-maven-plugin;>...
> @91:117) @
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml,
> line 91, column 117
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project io.fabric8:docker-jolokia-demo:0.15-SNAPSHOT
> (/Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml)
> has 1 error
> [ERROR] Malformed POM
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml:
> Unrecognised tag: 'm:configuration' (position: START_TAG seen
> ...che.org/POM/4.0.0" xmlns="http://fabric8.io/fabric8-maven-plugin;>...
> @91:117) @
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml,
> line 91, column 117 -> [Help 2]
> {code}
> It would be awesome if the XML parser would resolve namespaces properly. Its
> not about adding namespace features, only for plain XML resolving (each
> decent XML these days should be able to do this transparently).
> Except for
> https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
> I couldn't find any statement when namespaces are supported or tolerated.
> Are there any plans for this (and maybe also to relax the schema constraints
> on the {{}} tag) ?
> See also https://github.com/rhuss/poblano/issues/19 for a use case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7941) Meaning of -ntp CLI Option vs. --batch-mode
[
https://issues.apache.org/jira/browse/MNG-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7941:
-
Fix Version/s: 4.0.0-alpha-10
(was: 4.0.0-alpha-9)
> Meaning of -ntp CLI Option vs. --batch-mode
> ---
>
> Key: MNG-7941
> URL: https://issues.apache.org/jira/browse/MNG-7941
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.9.5, 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-10
>
>
> If you run a maven build while not downloaded all deps or even not downloaded
> any dependency at all you will see something like this on the console:
> {code}
> Downloading from nexus:
> http://localhost:8081/nexus/content/groups/public/org/apache/apache/31/apache-31.pom
> Progress (1): 7.9/24 kB
> Progress (1): 24 kB
> ...
> Downloading from nexus:
> http://localhost:8081/nexus/content/groups/public/org/eclipse/jetty/jetty-security/9.4.46.v20220331/jetty-security-9.4.46.v20220331.jar
> Progress (3): 106/733 kB | 73/225 kB | 73/184 kB
> Progress (3): 139/733 kB | 73/225 kB | 73/184 kB
> Progress (3): 139/733 kB | 106/225 kB | 73/184 kB
> Progress (3): 172/733 kB | 106/225 kB | 73/184 kB
> Progress (3): 172/733 kB | 106/225 kB | 106/184 kB
> Progress (3): 204/733 kB | 106/225 kB | 106/184 kB
> Progress (3): 204/733 kB | 139/225 kB | 106/184 kB
> Progress (3): 204/733 kB | 139/225 kB | 139/184 kB
> Progress (3): 237/733 kB | 139/225 kB | 139/184 kB
> Progress (3): 237/733 kB | 172/225 kB | 139/184 kB
> Progress (3): 237/733 kB | 172/225 kB | 172/184 kB
> Progress (3): 237/733 kB | 172/225 kB | 184 kB
> Progress (3): 270/733 kB | 172/225 kB | 184 kB
> Progress (3): 270/733 kB | 204/225 kB | 184 kB
> Progress (3): 270/733 kB | 225 kB | 184 kB
> Progress (4): 270/733 kB | 225 kB | 184 kB | 7.9/147 kB
> Progress (4): 303/733 kB | 225 kB | 184 kB | 7.9/147 kB
> ...
> {code}
> So far as usual..
> What you can do to prevent the long outputs is just use: {{--batch-mode}}
> which prevents the output of the progress and the result looks like this:
> {code}
> [INFO] Downloaded from nexus:
> http://localhost:8081/nexus/content/groups/public/org/apache/maven/doxia/doxia-module-twiki/1.11.1/doxia-module-twiki-1.11.1.jar
> (73 kB at 1.4 MB/s)
> [INFO] Downloading from nexus:
> http://localhost:8081/nexus/content/groups/public/org/eclipse/jetty/jetty-security/9.4.46.v20220331/jetty-security-9.4.46.v20220331.jar
> [INFO] Downloaded from nexus:
> http://localhost:8081/nexus/content/groups/public/org/eclipse/jetty/jetty-io/9.4.46.v20220331/jetty-io-9.4.46.v20220331.jar
> (184 kB at 3.4 MB/s)
> [INFO] Downloading from nexus:
> http://localhost:8081/nexus/content/groups/public/org/eclipse/jetty/jetty-util-ajax/9.4.46.v20220331/jetty-util-ajax-9.4.46.v20220331.jar
> ...
> {code}
> So finally you can use {{-no-transfer-progress}} (or {{-ntp}}) and the output
> looks like this:
> {code}
> [INFO]
> [INFO] --- site:3.12.1:attach-descriptor (attach-descriptor) @
> maven-dependency-plugin ---
> [INFO] Skipping because packaging 'maven-plugin' is not pom.
> [INFO]
> [INFO] --- install:3.1.1:install (default-install) @ maven-dependency-plugin
> ---
> ..
> {code}
> So based on the naming of {{\-\-no-transfer-progress}} which is a bit
> misleading because the transfer progress output has already been supressed by
> using {{--batch-mode}}.
> For Maven 4 we could think about a more cleaner way:
> * {{--batch-mode}} will not change anything
> * {{--no-transfer-progress}} will prevent the output of {{Progress (3):
> 237/733 kB | 172/225 kB | 172/184 kB}} (which will really represent the
> function related to the name).
> * {{--no-download-output}} could suppress the output as of using {{-ntp}} in
> Maven 3.X
> That would be a bit more consistent
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7897) Suport ${project.rootDirectory} in file profile activation
[
https://issues.apache.org/jira/browse/MNG-7897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7897:
-
Fix Version/s: 4.0.0-alpha-10
(was: 4.0.0-alpha-9)
> Suport ${project.rootDirectory} in file profile activation
> --
>
> Key: MNG-7897
> URL: https://issues.apache.org/jira/browse/MNG-7897
> Project: Maven
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 4.0.0-alpha-10
>
>
> In current code we have support for short properties: {{rootDirectory}} to be
> consistence we should use {{project.rootDirectory}}
> Property {{project.rootDirectory}} was introduced in MNG-7038, as we in alpha
> release we can change it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode
[
https://issues.apache.org/jira/browse/MNG-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7919.
Resolution: Fixed
> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 4.0.0-alpha-9, 4.0.0
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}}
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the
> root directory or add the root="true" attribute on the root project's model
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime:
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in
> debug mode? I would say report it not only in DEBUG mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode
[
https://issues.apache.org/jira/browse/MNG-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7919:
Assignee: Guillaume Nodet
> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 4.0.0-alpha-9, 4.0.0
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}}
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the
> root directory or add the root="true" attribute on the root project's model
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime:
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in
> debug mode? I would say report it not only in DEBUG mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7938) Upgrade plexus classworlds to 2.7.0
[ https://issues.apache.org/jira/browse/MNG-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7938: - Fix Version/s: 4.0.0-alpha-10 (was: 4.0.0-alpha-9) > Upgrade plexus classworlds to 2.7.0 > --- > > Key: MNG-7938 > URL: https://issues.apache.org/jira/browse/MNG-7938 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-8 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [I] Failed to install artifact xxx [maven-mvnd]
cstamas commented on issue #862: URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1847483597 @harryssuperman The upcoming Maven 4.0.0-alpha-9 contains the fix as well: 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-450) Add a RepositoryCache#computeIfAbsent method
[ https://issues.apache.org/jira/browse/MRESOLVER-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794793#comment-17794793 ] ASF GitHub Bot commented on MRESOLVER-450: -- cstamas opened a new pull request, #392: URL: https://github.com/apache/maven-resolver/pull/392 Enhance RepositoryCache --- https://issues.apache.org/jira/browse/MRESOLVER-450 > Add a RepositoryCache#computeIfAbsent method > > > Key: MRESOLVER-450 > URL: https://issues.apache.org/jira/browse/MRESOLVER-450 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Similar to MRESOLVER-204, improvement for RepositoryCache -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-450) Add a RepositoryCache#computeIfAbsent method
Tamas Cservenak created MRESOLVER-450: - Summary: Add a RepositoryCache#computeIfAbsent method Key: MRESOLVER-450 URL: https://issues.apache.org/jira/browse/MRESOLVER-450 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0 Similar to MRESOLVER-204, improvement for RepositoryCache -- 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-1847472348 Hi folks, after setting/installing the new maven version 3.9.6, all builds are running now with and without wrapper fine for a week yet. because @chenfeg started the issue with Maven 4.0.0.alpha5 i was checking if the alpha was updated too. I am not sure if the problem/bug will be fixed into the alpha 9. But if so, could you @chenfeg test it? and eventually closing issue?. Thanks a lot. -- 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] [MJARSIGNER-41] Retry and delay feature when signing [maven-jarsigner-plugin]
schedin commented on code in PR #13:
URL:
https://github.com/apache/maven-jarsigner-plugin/pull/13#discussion_r1420602906
##
src/main/java/org/apache/maven/plugins/jarsigner/AbstractJarsignerMojo.java:
##
@@ -251,78 +250,80 @@ public abstract class AbstractJarsignerMojo extends
AbstractMojo {
@Component(hint = "mng-4384")
private SecDispatcher securityDispatcher;
+@Override
public final void execute() throws MojoExecutionException {
-if (!this.skip) {
-Toolchain toolchain = getToolchain();
+if (this.skip) {
+getLog().info(getMessage("disabled"));
+return;
+}
Review Comment:
I did an indentation change for this method that my IDE showed nicely, but
GitHub diff goes bananas over it. I could change it back. However in the scope
of https://issues.apache.org/jira/projects/MJARSIGNER/issues/MJARSIGNER-72 I
still plan to refactor this method. I'm not sure if MJARSIGNER-72 will be
accepted by the community, but I will still implement it because I have a
direct need for it.
--
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] [MJARSIGNER-41] Retry and delay feature when signing [maven-jarsigner-plugin]
schedin commented on code in PR #13:
URL:
https://github.com/apache/maven-jarsigner-plugin/pull/13#discussion_r1420597254
##
src/main/java/org/apache/maven/plugins/jarsigner/JarsignerSignMojo.java:
##
@@ -126,4 +155,62 @@ protected JarSignerRequest createRequest(File archive)
throws MojoExecutionExcep
request.setKeypass(decrypt(keypass));
return request;
}
+
+/**
+ * {@inheritDoc}
+ *
+ * Will retry signing up to maxTries times if it fails.
+ *
+ * @throws MojoExecutionException If all signing attempts fail.
+ */
+@Override
+protected void executeJarSigner(JarSigner jarSigner, JarSignerRequest
request)
+throws JavaToolException, MojoExecutionException {
+Commandline commandLine = null;
+int resultCode = 0;
+for (int attempt = 0; attempt < maxTries; attempt++) {
+JavaToolResult result = jarSigner.execute(request);
+resultCode = result.getExitCode();
+commandLine = result.getCommandline();
+if (resultCode == 0) {
+return;
+}
+if (attempt < maxTries - 1) { // If not last attempt
+waitStrategy.waitAfterFailure(attempt,
Duration.ofSeconds(maxRetryDelaySeconds));
+}
+}
+throw new MojoExecutionException(getMessage("failure",
getCommandlineInfo(commandLine), resultCode));
+}
+
+/** Set current WaitStrategy. Package private for testing. */
+void setWaitStrategy(WaitStrategy waitStrategy) {
+this.waitStrategy = waitStrategy;
+}
+
+/** Wait/sleep after a signing failure before the next re-try should
happen. */
+@FunctionalInterface
+interface WaitStrategy {
+/**
+ * Will be called after a signing failure, if a re-try is about to
happen. May as a side effect sleep current
+ * thread for some time.
+ * @param attempt the attempt number (0 is the first).
+ * @param maxRetryDelay The maximum duration to sleep (may be zero).
+ * @throws MojoExecutionException If the sleep was interrupted.
+ */
+void waitAfterFailure(int attempt, Duration maxRetryDelay) throws
MojoExecutionException;
+}
+
+private void defaultWaitStrategy(int attempt, Duration maxRetryDelay)
throws MojoExecutionException {
+long delayMillis = (long) (Duration.ofSeconds(1).toMillis() *
Math.pow(2, attempt));
Review Comment:
Refactored method to make it testable. Added test case
`JarsignerSignMojoRetryTest.testDefaultWaitStrategy()` that tests/proves that
there are no unexpected overflow/wraparound problems (at least not visible from
the outside).
--
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] [MJARSIGNER-41] Retry and delay feature when signing [maven-jarsigner-plugin]
schedin commented on code in PR #13:
URL:
https://github.com/apache/maven-jarsigner-plugin/pull/13#discussion_r1420595655
##
src/main/java/org/apache/maven/plugins/jarsigner/JarsignerSignMojo.java:
##
@@ -126,4 +155,62 @@ protected JarSignerRequest createRequest(File archive)
throws MojoExecutionExcep
request.setKeypass(decrypt(keypass));
return request;
}
+
+/**
+ * {@inheritDoc}
+ *
+ * Will retry signing up to maxTries times if it fails.
+ *
+ * @throws MojoExecutionException If all signing attempts fail.
+ */
+@Override
+protected void executeJarSigner(JarSigner jarSigner, JarSignerRequest
request)
+throws JavaToolException, MojoExecutionException {
+Commandline commandLine = null;
+int resultCode = 0;
+for (int attempt = 0; attempt < maxTries; attempt++) {
Review Comment:
Fixed via `JarsignerSignMojo.validateParameters()`.
--
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-7955) Plugins should be allowed some control over the imported packages
Guillaume Nodet created MNG-7955:
Summary: Plugins should be allowed some control over the imported
packages
Key: MNG-7955
URL: https://issues.apache.org/jira/browse/MNG-7955
Project: Maven
Issue Type: New Feature
Reporter: Guillaume Nodet
Fix For: 4.0.0
We need some simple configuration to allow plugins to indicate which packages /
artifacts they need to be provided. This could solve the problems with
{{org.slf4j}} package.
I think the defaults could be the following packages:
* org.apache.maven.api,org.apache.maven.api.*
* org.sl4j
* jarkata.inject
See
[https://github.com/apache/maven/pull/1336|https://github.com/apache/maven/pull/1336/files#diff-9600f93ce04acabe017b026dc1ebbb445e8cb363bb2677a764a783ab85cf804aR106-R108]
which is related.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJARSIGNER-41] Retry and delay feature when signing [maven-jarsigner-plugin]
schedin commented on code in PR #13:
URL:
https://github.com/apache/maven-jarsigner-plugin/pull/13#discussion_r1420595140
##
src/main/java/org/apache/maven/plugins/jarsigner/JarsignerSignMojo.java:
##
@@ -90,6 +94,30 @@ public class JarsignerSignMojo extends AbstractJarsignerMojo
{
@Parameter(property = "jarsigner.certchain", readonly = true, required =
false)
private File certchain;
+/**
+ * How many times to try to sign a jar (assuming each previous attempt is
a failure). This option may be desirable
+ * if any network operations are used during signing, for example using a
Time Stamp Authority or network based
+ * PKCS11 HSM solution for storing code signing keys.
+ *
+ * The default value of 1 indicate that no retries should be made.
Review Comment:
Added method `AbstractJarsignerMojo.validateParameters()` and overridden in
`JarsignerSignMojo`. Added `maxTries` and `maxRetryDelaySeconds` contraint
check that will reset to default values and log if checks fail. Also added test
cases to verify correct behaviour (see `JarsignerSignMojoRetryTest` and methods
`testInvalidMaxTries_zero()`, `testInvalidMaxTries_negative()`,
`testMaxRetryDelaySeconds()`, `testInvalidMaxRetryDelaySeconds_negative()`).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MNG-7954) Provide a cleaner DI api
[
https://issues.apache.org/jira/browse/MNG-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7954:
-
Description:
With https://issues.apache.org/jira/browse/MNG-7947 the {{jakarta.inject}}
package has been brought into the API.
We need a cleaner way and not depend on any third party library if possible.
The
[{{SessionScope}}|https://github.com/apache/maven/blob/23bca281fcd084ac21d80f5a2950dcee30a19080/maven-core/src/main/java/org/apache/maven/session/scope/internal/SessionScope.java#L123-L125]
would also require some cleaning to avoid having to rely on
{{{}(org.eclipse.sisu|javax.enterprise.inject|jakarta.enterprise.inject).Typed{}}}.
For complete DI, we may also miss the sisu annotations ({{{}PostConstruct{}}},
{{PreDestroy}} and {{Priority}} and {{{}EagerSingleton{}}}.
was:
With https://issues.apache.org/jira/browse/MNG-7947 the {{jakarta.inject}}
package has been brought into the API.
We need a cleaner way and not depend on any third party library if possible.
The
[{{SessionScope}}|https://github.com/apache/maven/blob/23bca281fcd084ac21d80f5a2950dcee30a19080/maven-core/src/main/java/org/apache/maven/session/scope/internal/SessionScope.java#L123-L125]
would also require some cleaning to avoid having to rely on
{{(org.eclipse.sisu|javax.enterprise.inject|jakarta.enterprise.inject).Typed}}.
For complete DI, we may also miss some JSR 250 annotations ({{PostConstruct}},
{{PreDestroy}} and {{Priority}}).
> Provide a cleaner DI api
>
>
> Key: MNG-7954
> URL: https://issues.apache.org/jira/browse/MNG-7954
> Project: Maven
> Issue Type: New Feature
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0
>
>
> With https://issues.apache.org/jira/browse/MNG-7947 the {{jakarta.inject}}
> package has been brought into the API.
> We need a cleaner way and not depend on any third party library if possible.
> The
> [{{SessionScope}}|https://github.com/apache/maven/blob/23bca281fcd084ac21d80f5a2950dcee30a19080/maven-core/src/main/java/org/apache/maven/session/scope/internal/SessionScope.java#L123-L125]
> would also require some cleaning to avoid having to rely on
> {{{}(org.eclipse.sisu|javax.enterprise.inject|jakarta.enterprise.inject).Typed{}}}.
> For complete DI, we may also miss the sisu annotations
> ({{{}PostConstruct{}}}, {{PreDestroy}} and {{Priority}} and
> {{{}EagerSingleton{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Restrict classloader for Maven 4 plugins [maven]
gnodet commented on code in PR #1336: URL: https://github.com/apache/maven/pull/1336#discussion_r1420563752 ## maven-core/src/main/resources/META-INF/maven/extension.xml: ## @@ -187,6 +189,7 @@ under the License. org.apache.maven.resolver:maven-resolver-util org.apache.maven.resolver:maven-resolver-connector-basic +jakarta.inject:jakarta.inject-api Review Comment: I've raised https://issues.apache.org/jira/browse/MNG-7954 -- 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-7954) Provide a cleaner DI api
Guillaume Nodet created MNG-7954:
Summary: Provide a cleaner DI api
Key: MNG-7954
URL: https://issues.apache.org/jira/browse/MNG-7954
Project: Maven
Issue Type: New Feature
Reporter: Guillaume Nodet
Fix For: 4.0.0
With https://issues.apache.org/jira/browse/MNG-7947 the {{jakarta.inject}}
package has been brought into the API.
We need a cleaner way and not depend on any third party library if possible.
The
[{{SessionScope}}|https://github.com/apache/maven/blob/23bca281fcd084ac21d80f5a2950dcee30a19080/maven-core/src/main/java/org/apache/maven/session/scope/internal/SessionScope.java#L123-L125]
would also require some cleaning to avoid having to rely on
{{(org.eclipse.sisu|javax.enterprise.inject|jakarta.enterprise.inject).Typed}}.
For complete DI, we may also miss some JSR 250 annotations ({{PostConstruct}},
{{PreDestroy}} and {{Priority}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1341) Convert tests to Junit 5
[ https://issues.apache.org/jira/browse/MSHARED-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSHARED-1341: -- Fix Version/s: maven-filtering-3.3.2 > Convert tests to Junit 5 > > > Key: MSHARED-1341 > URL: https://issues.apache.org/jira/browse/MSHARED-1341 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-filtering-3.3.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSHARED-1341) Convert tests to Junit 5
[ https://issues.apache.org/jira/browse/MSHARED-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-1341: - Assignee: Sylwester Lachiewicz > Convert tests to Junit 5 > > > Key: MSHARED-1341 > URL: https://issues.apache.org/jira/browse/MSHARED-1341 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-filtering-3.3.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1339) Upgrade parent POM to version 41
[ https://issues.apache.org/jira/browse/MSHARED-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MSHARED-1339. - Fix Version/s: maven-filtering-3.3.2 Resolution: Fixed > Upgrade parent POM to version 41 > > > Key: MSHARED-1339 > URL: https://issues.apache.org/jira/browse/MSHARED-1339 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-filtering-3.3.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSHARED-1339) Upgrade parent POM to version 41
[ https://issues.apache.org/jira/browse/MSHARED-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-1339: - Assignee: Sylwester Lachiewicz > Upgrade parent POM to version 41 > > > Key: MSHARED-1339 > URL: https://issues.apache.org/jira/browse/MSHARED-1339 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794727#comment-17794727
]
Patrik Dudits commented on MBUILDCACHE-73:
--
{quote}TBH this is the simple (and natural) solution for this.
{quote}
I agree that that's simple and obvious solution.
{quote}Maven is always based on gav so why not here as well{quote}
Because then it is not possible to utilize cache to improve natural Maven
release flow, which has always been bit wasteful. Especially since my project
is bit on the larger side, and has quite long integration test phase. Let's
compare the current and future situation:
||Action||Cache without version||Cache with version||
|1.0-SNAPSHOT, release:prepare|Cache utilized|version changes during prepare,
no cache, Full 1h build|
|1.0, release:perform|Full 1h build, because I turn off cache for release
builds|Full Build|
|1.1-SNAPSHOT, regular build|Cache utilized (but misses deploy)|Full Build|
So with version being part of has I will get 2 extra full builds, going from 1
hour to 3 hours build time. That's why the proposed solution doesn't make me
happy, even if it is appropriate. I'd rather have it optional (but turned on by
default).
There are some other cases when I would still welcome reconcilation expression.
One of them would be that I want to rebuild docker image whenever base image
changes. I can run a script before the build to extract current tag of base
images and export them in environment. I would then want this environment value
to drive whether I want to execute docker:build.
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MSHARED-1290) PropertyUtils cycle detection results in false positives
[
https://issues.apache.org/jira/browse/MSHARED-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MSHARED-1290.
Resolution: Fixed
> PropertyUtils cycle detection results in false positives
>
>
> Key: MSHARED-1290
> URL: https://issues.apache.org/jira/browse/MSHARED-1290
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0, maven-filtering-3.3.0,
> maven-filtering-3.3.1
>Reporter: Wouter Born
>Priority: Major
>
> I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
> and found that {{PropertyUtils}} was logging many false positives about
> cycles between properties.
> The cycle detection (introduced for MSHARED-417) reports false positives when
> a variable occurs multiple times in a property, example:
> {code:java}
> depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
> version=1.2.3 {code}
> While writing a unit test to fix this, I also found that there are also cycle
> false positives whenever one of the property values is the same as a property
> name, example:
> {code:java}
> test1=${test2}
> test2=${test3}
> test3=test2{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1290) PropertyUtils cycle detection results in false positives
[
https://issues.apache.org/jira/browse/MSHARED-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794718#comment-17794718
]
ASF GitHub Bot commented on MSHARED-1290:
-
elharo merged PR #78:
URL: https://github.com/apache/maven-filtering/pull/78
> PropertyUtils cycle detection results in false positives
>
>
> Key: MSHARED-1290
> URL: https://issues.apache.org/jira/browse/MSHARED-1290
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0, maven-filtering-3.3.0,
> maven-filtering-3.3.1
>Reporter: Wouter Born
>Priority: Major
>
> I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
> and found that {{PropertyUtils}} was logging many false positives about
> cycles between properties.
> The cycle detection (introduced for MSHARED-417) reports false positives when
> a variable occurs multiple times in a property, example:
> {code:java}
> depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
> version=1.2.3 {code}
> While writing a unit test to fix this, I also found that there are also cycle
> false positives whenever one of the property values is the same as a property
> name, example:
> {code:java}
> test1=${test2}
> test2=${test3}
> test3=test2{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1290) PropertyUtils cycle detection results in false positives
[
https://issues.apache.org/jira/browse/MSHARED-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MSHARED-1290.
--
> PropertyUtils cycle detection results in false positives
>
>
> Key: MSHARED-1290
> URL: https://issues.apache.org/jira/browse/MSHARED-1290
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.2.0, maven-filtering-3.3.0,
> maven-filtering-3.3.1
>Reporter: Wouter Born
>Priority: Major
>
> I upgraded the maven-assembly-plugin in one of my projects from 2.6 to 3.6.0
> and found that {{PropertyUtils}} was logging many false positives about
> cycles between properties.
> The cycle detection (introduced for MSHARED-417) reports false positives when
> a variable occurs multiple times in a property, example:
> {code:java}
> depends=p1 >= ${version}, p2 >= ${version}, p3 >= ${version}
> version=1.2.3 {code}
> While writing a unit test to fix this, I also found that there are also cycle
> false positives whenever one of the property values is the same as a property
> name, example:
> {code:java}
> test1=${test2}
> test2=${test3}
> test3=test2{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1290] Fix PropertyUtils cycle detection results in false positives [maven-filtering]
elharo merged PR #78: URL: https://github.com/apache/maven-filtering/pull/78 -- 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] [MSHARED-1339] Bump org.apache.maven.shared:maven-shared-components from 39 to 41 [maven-filtering]
elharo merged PR #85: URL: https://github.com/apache/maven-filtering/pull/85 -- 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] (MSHARED-1339) Upgrade parent POM to version 41
[ https://issues.apache.org/jira/browse/MSHARED-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794717#comment-17794717 ] ASF GitHub Bot commented on MSHARED-1339: - elharo merged PR #85: URL: https://github.com/apache/maven-filtering/pull/85 > Upgrade parent POM to version 41 > > > Key: MSHARED-1339 > URL: https://issues.apache.org/jira/browse/MSHARED-1339 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering >Reporter: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJARSIGNER-63) certchain should be supported by default
[ https://issues.apache.org/jira/browse/MJARSIGNER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794704#comment-17794704 ] ASF GitHub Bot commented on MJARSIGNER-63: -- schedin commented on PR #14: URL: https://github.com/apache/maven-jarsigner-plugin/pull/14#issuecomment-1847147734 Even though `readonly` is not about documentation (primary), I feel that in this context (for this specific case and JIRA tickets) it is about documentation. In my comment in https://issues.apache.org/jira/projects/MJARSIGNER/issues/MJARSIGNER-63 I have provided a (rather long) example that shows that it is possible to set this parameter, even if it is readonly (or undocumented). My opinion is that we (the community) should make a conscious choice to make sure that this parameter is configurable by the end-user (and also documented). I think this was the original intent of https://issues.apache.org/jira/projects/MJARSIGNER/issues/MJARSIGNER-53 > certchain should be supported by default > > > Key: MJARSIGNER-63 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-63 > Project: Maven Jar Signer Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Manfred Koch >Priority: Major > > The certchain parameter of the jarsigne should be also supported by the Maven > plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MJARSIGNER-63] Exposing certchain on site sign-goal documentation [maven-jarsigner-plugin]
schedin commented on PR #14: URL: https://github.com/apache/maven-jarsigner-plugin/pull/14#issuecomment-1847147734 Even though `readonly` is not about documentation (primary), I feel that in this context (for this specific case and JIRA tickets) it is about documentation. In my comment in https://issues.apache.org/jira/projects/MJARSIGNER/issues/MJARSIGNER-63 I have provided a (rather long) example that shows that it is possible to set this parameter, even if it is readonly (or undocumented). My opinion is that we (the community) should make a conscious choice to make sure that this parameter is configurable by the end-user (and also documented). I think this was the original intent of https://issues.apache.org/jira/projects/MJARSIGNER/issues/MJARSIGNER-53 -- 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] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794700#comment-17794700
]
ASF GitHub Bot commented on MSHARED-1285:
-
laeubi commented on code in PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420419510
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -189,20 +190,44 @@ public void filterResources(MavenResourcesExecution
mavenResourcesExecution) thr
// as destination
// see MNG-1345
File outputDirectory =
mavenResourcesExecution.getOutputDirectory();
-boolean outputExists = outputDirectory.exists();
-if (!outputExists && !outputDirectory.mkdirs()) {
+if (!outputDirectory.mkdirs() && !outputDirectory.exists()) {
throw new MavenFilteringException("Cannot create resource
output directory: " + outputDirectory);
}
if (resource.isFiltering()) {
isFilteringUsed = true;
}
-boolean ignoreDelta = !outputExists
-||
buildContext.hasDelta(mavenResourcesExecution.getFileFilters())
-||
buildContext.hasDelta(getRelativeOutputDirectory(mavenResourcesExecution));
-LOGGER.debug("ignoreDelta " + ignoreDelta);
-Scanner scanner = buildContext.newScanner(resourceDirectory,
ignoreDelta);
+boolean filtersFileChanges =
buildContext.hasDelta(mavenResourcesExecution.getFileFilters());
Review Comment:
Done
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
laeubi commented on code in PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420419510
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -189,20 +190,44 @@ public void filterResources(MavenResourcesExecution
mavenResourcesExecution) thr
// as destination
// see MNG-1345
File outputDirectory =
mavenResourcesExecution.getOutputDirectory();
-boolean outputExists = outputDirectory.exists();
-if (!outputExists && !outputDirectory.mkdirs()) {
+if (!outputDirectory.mkdirs() && !outputDirectory.exists()) {
throw new MavenFilteringException("Cannot create resource
output directory: " + outputDirectory);
}
if (resource.isFiltering()) {
isFilteringUsed = true;
}
-boolean ignoreDelta = !outputExists
-||
buildContext.hasDelta(mavenResourcesExecution.getFileFilters())
-||
buildContext.hasDelta(getRelativeOutputDirectory(mavenResourcesExecution));
-LOGGER.debug("ignoreDelta " + ignoreDelta);
-Scanner scanner = buildContext.newScanner(resourceDirectory,
ignoreDelta);
+boolean filtersFileChanges =
buildContext.hasDelta(mavenResourcesExecution.getFileFilters());
Review Comment:
Done
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794697#comment-17794697
]
ASF GitHub Bot commented on MSHARED-1285:
-
elharo commented on code in PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420408887
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -189,20 +190,44 @@ public void filterResources(MavenResourcesExecution
mavenResourcesExecution) thr
// as destination
// see MNG-1345
File outputDirectory =
mavenResourcesExecution.getOutputDirectory();
-boolean outputExists = outputDirectory.exists();
-if (!outputExists && !outputDirectory.mkdirs()) {
+if (!outputDirectory.mkdirs() && !outputDirectory.exists()) {
throw new MavenFilteringException("Cannot create resource
output directory: " + outputDirectory);
}
if (resource.isFiltering()) {
isFilteringUsed = true;
}
-boolean ignoreDelta = !outputExists
-||
buildContext.hasDelta(mavenResourcesExecution.getFileFilters())
-||
buildContext.hasDelta(getRelativeOutputDirectory(mavenResourcesExecution));
-LOGGER.debug("ignoreDelta " + ignoreDelta);
-Scanner scanner = buildContext.newScanner(resourceDirectory,
ignoreDelta);
+boolean filtersFileChanges =
buildContext.hasDelta(mavenResourcesExecution.getFileFilters());
Review Comment:
filtersFileChanged? since "changes" sounds like it's the actual changes
instead of a boolean indicating whether things changed
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
elharo commented on code in PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420408887
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -189,20 +190,44 @@ public void filterResources(MavenResourcesExecution
mavenResourcesExecution) thr
// as destination
// see MNG-1345
File outputDirectory =
mavenResourcesExecution.getOutputDirectory();
-boolean outputExists = outputDirectory.exists();
-if (!outputExists && !outputDirectory.mkdirs()) {
+if (!outputDirectory.mkdirs() && !outputDirectory.exists()) {
throw new MavenFilteringException("Cannot create resource
output directory: " + outputDirectory);
}
if (resource.isFiltering()) {
isFilteringUsed = true;
}
-boolean ignoreDelta = !outputExists
-||
buildContext.hasDelta(mavenResourcesExecution.getFileFilters())
-||
buildContext.hasDelta(getRelativeOutputDirectory(mavenResourcesExecution));
-LOGGER.debug("ignoreDelta " + ignoreDelta);
-Scanner scanner = buildContext.newScanner(resourceDirectory,
ignoreDelta);
+boolean filtersFileChanges =
buildContext.hasDelta(mavenResourcesExecution.getFileFilters());
Review Comment:
filtersFileChanged? since "changes" sounds like it's the actual changes
instead of a boolean indicating whether things changed
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MJARSIGNER-63) certchain should be supported by default
[ https://issues.apache.org/jira/browse/MJARSIGNER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794694#comment-17794694 ] ASF GitHub Bot commented on MJARSIGNER-63: -- elharo commented on PR #14: URL: https://github.com/apache/maven-jarsigner-plugin/pull/14#issuecomment-1847124242 It's possible that this should not have readonly=true. I don't have a real opinion on that. But let's make sure we're making conscious choice here and the PR title reflects what we're trying to do. > certchain should be supported by default > > > Key: MJARSIGNER-63 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-63 > Project: Maven Jar Signer Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Manfred Koch >Priority: Major > > The certchain parameter of the jarsigne should be also supported by the Maven > plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MJARSIGNER-63] Exposing certchain on site sign-goal documentation [maven-jarsigner-plugin]
elharo commented on PR #14: URL: https://github.com/apache/maven-jarsigner-plugin/pull/14#issuecomment-1847124242 It's possible that this should not have readonly=true. I don't have a real opinion on that. But let's make sure we're making conscious choice here and the PR title reflects what we're trying to do. -- 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] (MJARSIGNER-65) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MJARSIGNER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794691#comment-17794691 ] Elliotte Rusty Harold commented on MJARSIGNER-65: - readonly is not about documentation. See https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#readonly() > Update parent pom to 39 > --- > > Key: MJARSIGNER-65 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-65 > Project: Maven Jar Signer Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJARSIGNER-63) certchain should be supported by default
[ https://issues.apache.org/jira/browse/MJARSIGNER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794692#comment-17794692 ] ASF GitHub Bot commented on MJARSIGNER-63: -- elharo commented on PR #14: URL: https://github.com/apache/maven-jarsigner-plugin/pull/14#issuecomment-1847123083 readonly is not about documentation. See https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#readonly() > certchain should be supported by default > > > Key: MJARSIGNER-63 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-63 > Project: Maven Jar Signer Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Manfred Koch >Priority: Major > > The certchain parameter of the jarsigne should be also supported by the Maven > plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794693#comment-17794693
]
ASF GitHub Bot commented on MSHARED-1285:
-
laeubi commented on code in PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420403517
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution
mavenResourcesExecution) thr
}
/**
- * Get the encoding to use when filtering the specified file. Properties
files can be configured to use a different
- * encoding than regular files.
+ * Get the encoding to use when filtering the specified file. Properties
files
+ * can be configured to use a different encoding than regular files.
*
- * @param file The file to check
- * @param encoding The encoding to use for regular files
+ * @param file The file to check
Review Comment:
I now reverted all unrelated javadoc changes
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
laeubi commented on code in PR #77: URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420403517 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java: ## @@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution mavenResourcesExecution) thr } /** - * Get the encoding to use when filtering the specified file. Properties files can be configured to use a different - * encoding than regular files. + * Get the encoding to use when filtering the specified file. Properties files + * can be configured to use a different encoding than regular files. * - * @param file The file to check - * @param encoding The encoding to use for regular files + * @param file The file to check Review Comment: I now reverted all unrelated javadoc changes -- 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] [MJARSIGNER-63] Exposing certchain on site sign-goal documentation [maven-jarsigner-plugin]
elharo commented on PR #14: URL: https://github.com/apache/maven-jarsigner-plugin/pull/14#issuecomment-1847123083 readonly is not about documentation. See https://maven.apache.org/plugin-tools/maven-plugin-annotations/apidocs/org/apache/maven/plugins/annotations/Parameter.html#readonly() -- 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] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794690#comment-17794690
]
ASF GitHub Bot commented on MSHARED-1285:
-
elharo commented on code in PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420397992
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution
mavenResourcesExecution) thr
}
/**
- * Get the encoding to use when filtering the specified file. Properties
files can be configured to use a different
- * encoding than regular files.
+ * Get the encoding to use when filtering the specified file. Properties
files
+ * can be configured to use a different encoding than regular files.
*
- * @param file The file to check
- * @param encoding The encoding to use for regular files
+ * @param file The file to check
Review Comment:
Did spotless do that? That's new, i think, and a strike against spotless if
so.
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
elharo commented on code in PR #77: URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420397992 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java: ## @@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution mavenResourcesExecution) thr } /** - * Get the encoding to use when filtering the specified file. Properties files can be configured to use a different - * encoding than regular files. + * Get the encoding to use when filtering the specified file. Properties files + * can be configured to use a different encoding than regular files. * - * @param file The file to check - * @param encoding The encoding to use for regular files + * @param file The file to check Review Comment: Did spotless do that? That's new, i think, and a strike against spotless if so. -- 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] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794687#comment-17794687
]
ASF GitHub Bot commented on MSHARED-1285:
-
laeubi commented on code in PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420394454
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution
mavenResourcesExecution) thr
}
/**
- * Get the encoding to use when filtering the specified file. Properties
files can be configured to use a different
- * encoding than regular files.
+ * Get the encoding to use when filtering the specified file. Properties
files
+ * can be configured to use a different encoding than regular files.
*
- * @param file The file to check
- * @param encoding The encoding to use for regular files
+ * @param file The file to check
Review Comment:
I use `spoltless:apply` to format the file according to project rules, so
not fully sure how to proceed, do you want me to revert the format changes from
spotles?
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
laeubi commented on code in PR #77: URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420394454 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java: ## @@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution mavenResourcesExecution) thr } /** - * Get the encoding to use when filtering the specified file. Properties files can be configured to use a different - * encoding than regular files. + * Get the encoding to use when filtering the specified file. Properties files + * can be configured to use a different encoding than regular files. * - * @param file The file to check - * @param encoding The encoding to use for regular files + * @param file The file to check Review Comment: I use `spoltless:apply` to format the file according to project rules, so not fully sure how to proceed, do you want me to revert the format changes from spotles? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.commons:commons-lang3 from 3.12.0 to 3.14.0 [maven-filtering]
elharo merged PR #84: URL: https://github.com/apache/maven-filtering/pull/84 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump commons-io:commons-io from 2.11.0 to 2.15.1 [maven-filtering]
elharo merged PR #86: URL: https://github.com/apache/maven-filtering/pull/86 -- 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] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794679#comment-17794679
]
ASF GitHub Bot commented on MSHARED-1285:
-
elharo commented on code in PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420388359
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution
mavenResourcesExecution) thr
}
/**
- * Get the encoding to use when filtering the specified file. Properties
files can be configured to use a different
- * encoding than regular files.
+ * Get the encoding to use when filtering the specified file. Properties
files
+ * can be configured to use a different encoding than regular files.
*
- * @param file The file to check
- * @param encoding The encoding to use for regular files
+ * @param file The file to check
Review Comment:
Probably better not to try to line these up. It's too hard to maintain.
But we should make the initial letter lower case in keeping with Oracle
guideline
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
elharo commented on code in PR #77: URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420388359 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java: ## @@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution mavenResourcesExecution) thr } /** - * Get the encoding to use when filtering the specified file. Properties files can be configured to use a different - * encoding than regular files. + * Get the encoding to use when filtering the specified file. Properties files + * can be configured to use a different encoding than regular files. * - * @param file The file to check - * @param encoding The encoding to use for regular files + * @param file The file to check Review Comment: Probably better not to try to line these up. It's too hard to maintain. But we should make the initial letter lower case in keeping with Oracle guideline -- 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] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794607#comment-17794607
]
ASF GitHub Bot commented on MSHARED-1285:
-
laeubi commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1846852881
All checks have passed!
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
laeubi commented on PR #77: URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1846852881 All checks have passed! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7951) Pick up resolver changes for VersionSchemeSelector
[ https://issues.apache.org/jira/browse/MNG-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7951: - Fix Version/s: 4.0.0-alpha-10 (was: 4.0.0-alpha-9) > Pick up resolver changes for VersionSchemeSelector > -- > > Key: MNG-7951 > URL: https://issues.apache.org/jira/browse/MNG-7951 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-10 > > > Resolver implemented MRESOLVER-446 and there is one component in > maven-resolver-provider that needs change to have Maven fully support > per-session VersionScheme. Also we should look for any other possible spots > as well... > This also supersedes MNG-7103 > Long term plan: this would allow us to kill off Maven Version > implementations, possibly reimplementing it as resolver' VersionScheme (it is > nicely UT covered) with all it's flaws, and then have explicit switch between > "legacy" (Maven Version) and "generic" (Resolver) version scheme, or maybe > even have some new future schemes as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7950) Support new version scheme selector in Maven
[ https://issues.apache.org/jira/browse/MNG-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7950: - Fix Version/s: 4.0.0-alpha-10 (was: 4.0.0-alpha-9) > Support new version scheme selector in Maven > > > Key: MNG-7950 > URL: https://issues.apache.org/jira/browse/MNG-7950 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-10 > > > The generic version scheme is made into component, but it is not enough: > there should be an indirection and extension point to support multiple > schemes. > Resolver introduces MRESOLVER-446 for that. > There is one component in Maven maven-resolver-provider module that needs to > be adapted, and use selector instead of ctor passed in scheme. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794603#comment-17794603
]
Olivier Lamy commented on MBUILDCACHE-73:
-
[~pdudits] but this will run only once :)
TBH this is the simple (and natural) solution for this.
Maven is always based on gav so why not here as well :)
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1285) DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
[
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794601#comment-17794601
]
ASF GitHub Bot commented on MSHARED-1285:
-
laeubi commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1846830645
@lalmeras sounds reasonable, I have now adjust the code accordingly (and
slightly restructured the flow), now my local build shows all test passing!
> DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes
> --
>
> Key: MSHARED-1285
> URL: https://issues.apache.org/jira/browse/MSHARED-1285
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: Christoph Läubrich
>Priority: Major
>
> The maven resources plugin uses
> [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java]
> to copy resources, but that component has some subtile flaws reported here:
> [https://github.com/eclipse-m2e/m2e-core/discussions/1468]
> The problematic part is the usage of BuildContext#newScanner that already
> mentions in the javadoc that passing ignoreDelta to neScanner might not
> reveal all required items +*for copy-resources*+ form A -> B and instead
> BuildContext#isUpTodate should be used.
> Just from a quick look I assume that part of code actually wants to use
> something like this:
> {code:java}
> DirectoryScanner ds = new DirectoryScanner() {
> @Override
> protected boolean isSelected(String name, File file) {
> if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file))
> {
> return false;
> }
> return true;
> }
> };
> ds.setBasedir(basedir); {code}
> That way all the code that currently checks for if output directory existed
> before can also be removed what is another issue because it leads to a full
> resources copy even if source+target are already even if a single class file
> is changed while the idea seems more that if the output was not there it
> should not try to be incremental!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]
laeubi commented on PR #77: URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1846830645 @lalmeras sounds reasonable, I have now adjust the code accordingly (and slightly restructured the flow), now my local build shows all test passing! -- 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] Version resolver API [maven]
gnodet merged PR #1335: URL: https://github.com/apache/maven/pull/1335 -- 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] (MSITE-988) Documentation
[ https://issues.apache.org/jira/browse/MSITE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794599#comment-17794599 ] Michael Osipov commented on MSITE-988: -- Yes, your understanding is correct and no, there is no such in-place tool. > Documentation > - > > Key: MSITE-988 > URL: https://issues.apache.org/jira/browse/MSITE-988 > Project: Maven Site Plugin > Issue Type: Bug > Components: documentation >Affects Versions: 4.0.0-M9 >Reporter: Ernst Reissner >Assignee: Michael Osipov >Priority: Major > > Create old pre-version 2.0.0 model. > If using newer versions, 4.0.0-M9 to the current M11, > then an error occurs: > ``` > Site model of > 'eu.simuline.m2latex:latex-maven-plugin:maven-plugin:2.0-SNAPSHOT' > for locale 'en' is still using the old pre-version 2.0.0 model. > You MUST migrate to the new model as soon as possible > otherwise your build will break in the future! > ``` > This is due to an old form of `site.xml` > The first problem is the documentation, > `https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html` > > which describes the old form and refers to the new one only in a link. > What would be needed is a clear statement on the mapping of the version to > the form. > Also the new form is not completely supported: > ``` >xmlns="http://maven.apache.org/SITE/2.0.0; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://maven.apache.org/SITE/2.0.0 > https://maven.apache.org/xsd/site-2.0.0.xsd;> > ... > > ``` > well, the link `https://maven.apache.org/xsd/site-2.0.0.xsd` does not exist, > resulting in a warning in my IDE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-335) Better resolver errors for Artifact Not Found
[
https://issues.apache.org/jira/browse/MRESOLVER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794594#comment-17794594
]
ASF GitHub Bot commented on MRESOLVER-335:
--
cstamas commented on PR #386:
URL: https://github.com/apache/maven-resolver/pull/386#issuecomment-1846798449
@slawekjaranowski as reporter, anything to add?
> Better resolver errors for Artifact Not Found
> -
>
> Key: MRESOLVER-335
> URL: https://issues.apache.org/jira/browse/MRESOLVER-335
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: 2.0.0
>
>
> When we have many remote repositories only first
> {{ArtifactNotFoundException}} is returned, all checks for other repositories
> are hidden.
> When we have errors for many artifacts in one request - list of problematic
> artifacts is present in message and only first exception for one artifact.
> Next case is with remote repository filtering, checks for remote repository
> according to filtering also produce {{ArtifactNotFoundException}}, this is
> done at the beginning so exception is first on list.
> In logs and exception we have:
> {code}
> Downloading from my-mirror:
> https://artifactory.../artifactory/remote-repos/org/apache/commons/commons-lang3/4.4.4/commons-lang3-4.4.4.pom
> [WARNING] The POM for org.apache.commons:commons-lang3:jar:4.4.4 is missing,
> no dependency information available
> Downloading from my-mirror:
> https://artifactory.../artifactory/remote-repos/org/apache/commons/commons-lang3/4.4.4/commons-lang3-4.4.4.jar
> [ERROR] Failed to execute goal on project maven-3.9: Could not resolve
> dependencies for project org.test:maven-3.9:jar:1.0.0-SNAPSHOT: Prefix org
> NOT allowed from mayrepo (https://artifactory.../artifactory/myrepo/,
> default, releases+snapshots)
> {code}
> As we see artefact was not found in {{my-mirror}}, but in error report we
> have information about not allowed prefixes - it can be confusing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-443) Integrate "configuration page generator" tool into build/site
[ https://issues.apache.org/jira/browse/MRESOLVER-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794595#comment-17794595 ] ASF GitHub Bot commented on MRESOLVER-443: -- cstamas commented on PR #385: URL: https://github.com/apache/maven-resolver/pull/385#issuecomment-1846798962 @michael-o anything to add here? > Integrate "configuration page generator" tool into build/site > - > > Key: MRESOLVER-443 > URL: https://issues.apache.org/jira/browse/MRESOLVER-443 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As part of MRESOLVER-440 we got a "tool" that basically generates this page: > [https://maven.apache.org/resolver/configuration.html] > It was manually authored before, that had many issues, was laborious and was > error prone. > This tool should be integrated somehow into "site", but unsure how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-443] Integrate tool into build [maven-resolver]
cstamas commented on PR #385: URL: https://github.com/apache/maven-resolver/pull/385#issuecomment-1846798962 @michael-o anything to add 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] [MRESOLVER-335] Proposal for better errors [maven-resolver]
cstamas commented on PR #386: URL: https://github.com/apache/maven-resolver/pull/386#issuecomment-1846798449 @slawekjaranowski as reporter, anything to add? -- 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] Dependency collection / resolution and version resolution API [maven]
gnodet merged PR #1333: URL: https://github.com/apache/maven/pull/1333 -- 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] (MJARSIGNER-63) certchain should be supported by default
[ https://issues.apache.org/jira/browse/MJARSIGNER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794585#comment-17794585 ] ASF GitHub Bot commented on MJARSIGNER-63: -- schedin commented on PR #14: URL: https://github.com/apache/maven-jarsigner-plugin/pull/14#issuecomment-1846763409 I have rebased this pull request on master. > certchain should be supported by default > > > Key: MJARSIGNER-63 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-63 > Project: Maven Jar Signer Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Manfred Koch >Priority: Major > > The certchain parameter of the jarsigne should be also supported by the Maven > plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MJARSIGNER-63] exposing certchain on site sign-goal documentation [maven-jarsigner-plugin]
schedin commented on PR #14: URL: https://github.com/apache/maven-jarsigner-plugin/pull/14#issuecomment-1846763409 I have rebased this pull request on master. -- 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
