[jira] [Commented] (DOXIA-709) Clarify usage of overlapping Sink methods

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/DOXIA-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790975#comment-17790975
 ] 

Konrad Windszus commented on DOXIA-709:
---

I would propose the following:
Implement default methods for all old methods without SinkEventAttributes 
parameter which just delegate to the equivalent with SinkEventAttributes and 
mention that in the javadoc accordingly.
Every Sink implementation should then be refactored to not override those 
default methods any longer.

> Clarify usage of overlapping Sink methods
> -
>
> Key: DOXIA-709
> URL: https://issues.apache.org/jira/browse/DOXIA-709
> Project: Maven Doxia
>  Issue Type: Improvement
>  Components: Sink API
>Reporter: Konrad Windszus
>Priority: Major
>
> With Doxia 1.1 new methods have been added taking an additional 
> {{SinkEventAttributes}} parameter. Semantically there is now an overlap, e.g. 
> between {{Sink.sectionTitle1}} and {{Sink.sectionTitle(1, null)}}
> It should be clear from the javadoc when which one is supposed to be called, 
> and also which one is the preferred method now.
> E.g. in {{SinkAdapter}} all new Doxia 1.1 methods taking a 
> {{SinkEventAttributes}} just forward to the equivalent method not taking it. 
> OTOH {{Xhtml5BaseSink}} delegates the other way around (e.g. for 
> {{link(String)}}) or does not delegate at all (e.g. for {{sectionTitle(int, 
> SinkEventAttributes)}} and {{sectionTitle1()}}).
> That leads to the fact that things are often not rendered consistently 
> although from their javadoc they should lead to the same result.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DOXIA-709) Clarify usage of overlapping Sink methods

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/DOXIA-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790982#comment-17790982
 ] 

Michael Osipov commented on DOXIA-709:
--

I need to look at this to understand the issue.

> Clarify usage of overlapping Sink methods
> -
>
> Key: DOXIA-709
> URL: https://issues.apache.org/jira/browse/DOXIA-709
> Project: Maven Doxia
>  Issue Type: Improvement
>  Components: Sink API
>Reporter: Konrad Windszus
>Priority: Major
>
> With Doxia 1.1 new methods have been added taking an additional 
> {{SinkEventAttributes}} parameter. Semantically there is now an overlap, e.g. 
> between {{Sink.sectionTitle1}} and {{Sink.sectionTitle(1, null)}}
> It should be clear from the javadoc when which one is supposed to be called, 
> and also which one is the preferred method now.
> E.g. in {{SinkAdapter}} all new Doxia 1.1 methods taking a 
> {{SinkEventAttributes}} just forward to the equivalent method not taking it. 
> OTOH {{Xhtml5BaseSink}} delegates the other way around (e.g. for 
> {{link(String)}}) or does not delegate at all (e.g. for {{sectionTitle(int, 
> SinkEventAttributes)}} and {{sectionTitle1()}}).
> That leads to the fact that things are often not rendered consistently 
> although from their javadoc they should lead to the same result.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Moved] (DOXIA-710) Inconsistent anchors between toc macro and headers

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/DOXIA-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus moved DOXIASITETOOLS-320 to DOXIA-710:
--

Component/s: (was: Site renderer)
Key: DOXIA-710  (was: DOXIASITETOOLS-320)
Project: Maven Doxia  (was: Maven Doxia Sitetools)

> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIA-710
> URL: https://issues.apache.org/jira/browse/DOXIA-710
> Project: Maven Doxia
>  Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
> 
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] [DOXIASITETOOLS-320] Auto-generate anchor for TOC entries [maven-doxia]

[via GitHub]

kwin commented on PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#issuecomment-1831556494

   > This seems like a reimplementation of RandomAccessSink: The 
RandomAccessSink provides the ability to create a {https://github.com/link 
Sink} with hooks. Why not evaluate it if it there.
   
   I was not aware of this class, but {{RandomAccessSink}} is complex to grasp 
for me. I would rather go for reimplementing RandomAccessSink as special 
SinkWrapper. AFAIK RandomAccessSink does not allow to intercept sink API calls 
and enrich them but just does some buffering and concatenating multiple sinks 
into one effective one.
   
   > This should not be related to the TOC macro although the TOC macro will 
benefit. A user can request auto anchors regardless of the TOC macro. Don't 
conflate them.
   
   For me the TOC is the primary use case, but I am ok with always generating 
anchors and TOC macro will just use those.
   
   > I think that a solution should be logically identical to 
org.apache.maven.doxia.parser.Parser.setEmitComments(boolean). A parser feature 
will intercept section title text and buffer until sectionTitle_() is hit, 
anchor and title (heading) are emitted.
   
   As long as the default is "emit anchors for every section title" I am fine 
with adding an option to disable that. I don't think we should make that an 
opt-in behaviour as that would be breaking change from a user's perspective.


-- 
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] (DOXIA-710) Inconsistent anchors between toc macro and headers

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/DOXIA-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790997#comment-17790997
 ] 

ASF GitHub Bot commented on DOXIA-710:
--

kwin commented on PR #180:
URL: https://github.com/apache/maven-doxia/pull/180#issuecomment-1831556494

   > This seems like a reimplementation of RandomAccessSink: The 
RandomAccessSink provides the ability to create a {https://github.com/link 
Sink} with hooks. Why not evaluate it if it there.
   
   I was not aware of this class, but {{RandomAccessSink}} is complex to grasp 
for me. I would rather go for reimplementing RandomAccessSink as special 
SinkWrapper. AFAIK RandomAccessSink does not allow to intercept sink API calls 
and enrich them but just does some buffering and concatenating multiple sinks 
into one effective one.
   
   > This should not be related to the TOC macro although the TOC macro will 
benefit. A user can request auto anchors regardless of the TOC macro. Don't 
conflate them.
   
   For me the TOC is the primary use case, but I am ok with always generating 
anchors and TOC macro will just use those.
   
   > I think that a solution should be logically identical to 
org.apache.maven.doxia.parser.Parser.setEmitComments(boolean). A parser feature 
will intercept section title text and buffer until sectionTitle_() is hit, 
anchor and title (heading) are emitted.
   
   As long as the default is "emit anchors for every section title" I am fine 
with adding an option to disable that. I don't think we should make that an 
opt-in behaviour as that would be breaking change from a user's perspective.




> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIA-710
> URL: https://issues.apache.org/jira/browse/DOXIA-710
> Project: Maven Doxia
>  Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
> 
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.



--
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]

[via GitHub]

lalmeras commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1831557819

   Already done it (copy/fix TestIncrementalBuildContext). It doesn't work out 
of the box as there is other tests that rely on this bug to work. And another 
bug in getRelpath.
   
   But I agree the best option is to retrieve/fix/adapt 
TestIncrementalBuildContext so that the 4 tests that use it work and actually 
test the effective filtering behavior. Just not as simple as it seems.
   
   I plan to work on it. I'll keep this issue updated about my work on it.
   
   Once the tests fixed, I think it'll be easier to write a test exposing the 
current issue.


-- 
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

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790998#comment-17790998
 ] 

ASF GitHub Bot commented on MSHARED-1285:
-

lalmeras commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1831557819

   Already done it (copy/fix TestIncrementalBuildContext). It doesn't work out 
of the box as there is other tests that rely on this bug to work. And another 
bug in getRelpath.
   
   But I agree the best option is to retrieve/fix/adapt 
TestIncrementalBuildContext so that the 4 tests that use it work and actually 
test the effective filtering behavior. Just not as simple as it seems.
   
   I plan to work on it. I'll keep this issue updated about my work on it.
   
   Once the tests fixed, I think it'll be easier to write a test exposing the 
current issue.




> 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
>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)

[jira] [Created] (MRESOLVER-445) Introduce MutableSession, a common ancestor for build and def impl

[Tamas Cservenak (Jira)]

Tamas Cservenak created MRESOLVER-445:
-

 Summary: Introduce MutableSession, a common ancestor for build and 
def impl
 Key: MRESOLVER-445
 URL: https://issues.apache.org/jira/browse/MRESOLVER-445
 Project: Maven Resolver
  Issue Type: Task
Reporter: Tamas Cservenak
 Fix For: 2.0.0


Reason is that this would simplify existing codebase upgrades, no need to 
maintain two execution paths.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[PR] Upgrade to Maven 4.0.0-alpha-9 [maven-plugin-tools]

[via GitHub]

gnodet opened a new pull request, #242:
URL: https://github.com/apache/maven-plugin-tools/pull/242

   (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] (MRESOLVER-445) Introduce MutableSession, a common ancestor for build and def impl

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791016#comment-17791016
 ] 

ASF GitHub Bot commented on MRESOLVER-445:
--

cstamas opened a new pull request, #383:
URL: https://github.com/apache/maven-resolver/pull/383

   Am unsure about this yet, hence draft/WIP yet.
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-445




> Introduce MutableSession, a common ancestor for build and def impl
> --
>
> Key: MRESOLVER-445
> URL: https://issues.apache.org/jira/browse/MRESOLVER-445
> Project: Maven Resolver
>  Issue Type: Task
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Reason is that this would simplify existing codebase upgrades, no need to 
> maintain two execution paths.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MDEP-901) Configure markersDirectory in UnpackMojo via Property

[Oliver Libutzki (Jira)]

Oliver Libutzki created MDEP-901:


 Summary: Configure markersDirectory in UnpackMojo via Property
 Key: MDEP-901
 URL: https://issues.apache.org/jira/browse/MDEP-901
 Project: Maven Dependency Plugin
  Issue Type: New Feature
Reporter: Oliver Libutzki


In contrast to _AbstractDependencyFilterMojo_ the _UnpackMojo_ does not support 
configuring the markersDirectory via Property. Especially for cli commands 
(without a pom.xml) it would be very helpful to have such a property.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7923) Jenkins core does not compile with Maven 4.x

[Basil Crow (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791201#comment-17791201
 ] 

Basil Crow commented on MNG-7923:
-

For context, see https://github.com/jenkinsci/incrementals-tools — and also 
note that this bug only occurs in Jenkins core, not in our other 
incrementalified multi-module Maven projects like 
https://github.com/jenkinsci/stapler and https://github.com/jenkinsci/jelly.

bq. I'd suggest to […] define the CI-friendly versions externally using system 
properties that can be defined in .mvn/maven.config

This has no effect.

> Jenkins core does not compile with Maven 4.x
> 
>
> Key: MNG-7923
> URL: https://issues.apache.org/jira/browse/MNG-7923
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-8
>Reporter: Basil Crow
>Priority: Major
>
> Try running {{git clone https://github.com/jenkinsci/jenkins.git && cd 
> jenkins && mvn verify -Pquick-build}}. On the latest version of Maven 3.x, it 
> works; on the latest Maven 4.x alpha, the build fails immediately with 
> "Non-resolvable import POM: The following artifacts could not be resolved". 
> If we need to make changes to our POM, then please point me to the 
> documentation; otherwise, please fix the bug and let me know which release of 
> Maven 4.x alpha I can test with the bug fixed. I bisected the failure to 
> MNG-6656 / 
> https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7787) Introduce new options for plugin validation

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791228#comment-17791228
 ] 

ASF GitHub Bot commented on MNG-7787:
-

hgschmie closed pull request #1116: [MNG-7787] Introduce new options for plugin 
validation report
URL: https://github.com/apache/maven/pull/1116




> Introduce new options for plugin validation
> ---
>
> Key: MNG-7787
> URL: https://issues.apache.org/jira/browse/MNG-7787
> Project: Maven
>  Issue Type: Improvement
>  Components: Plugins and Lifecycle
>Affects Versions: 3.9.2
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-7, 4.0.0
>
>
> Currently we offer following values for maven.plugin.validation:
>  * BRIEF - emits one liner WARN with count of plugins having validation 
> issues (IF count > 0)
>  * DEFAULT - emits one line for each plugin GAV having validation issues
>  * VERBOSE - emits detailed report for each plugin (declaration, use and 
> problems) for each plugin having validation issue
> We should introduce more:
>  * NONE - mute validation (usable on CI where plethora of WARNING lines could 
> lead to falsely detect build as unhealthy)
>  * INLINE - produce validation WARNs inline, as 3.9.1 did
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] [MNG-7787] Introduce new options for plugin validation report [maven]

[via GitHub]

hgschmie closed pull request #1116: [MNG-7787] Introduce new options for plugin 
validation report
URL: https://github.com/apache/maven/pull/1116


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7787) Introduce new options for plugin validation

[Henning Schmiedehausen (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791229#comment-17791229
 ] 

Henning Schmiedehausen commented on MNG-7787:
-

I closed it.

> Introduce new options for plugin validation
> ---
>
> Key: MNG-7787
> URL: https://issues.apache.org/jira/browse/MNG-7787
> Project: Maven
>  Issue Type: Improvement
>  Components: Plugins and Lifecycle
>Affects Versions: 3.9.2
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-7, 4.0.0
>
>
> Currently we offer following values for maven.plugin.validation:
>  * BRIEF - emits one liner WARN with count of plugins having validation 
> issues (IF count > 0)
>  * DEFAULT - emits one line for each plugin GAV having validation issues
>  * VERBOSE - emits detailed report for each plugin (declaration, use and 
> problems) for each plugin having validation issue
> We should introduce more:
>  * NONE - mute validation (usable on CI where plethora of WARNING lines could 
> lead to falsely detect build as unhealthy)
>  * INLINE - produce validation WARNs inline, as 3.9.1 did
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] [MRELEASE-1109] Support CI friendly versions [maven-release]

[via GitHub]

mkolesnikov commented on code in PR #198:
URL: https://github.com/apache/maven-release/pull/198#discussion_r1409822004


##
maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModel.java:
##
@@ -189,7 +192,17 @@ public void setVersion(String version) {
 project.addContent(index + 2, versionElement);
 }
 } else {
-JDomUtils.rewriteValue(versionElement, version);
+if 
(AbstractRewritePomsPhase.isCiFriendlyVersion(versionElement.getTextNormalize()))
 {
+// try to rewrite property if CI friendly expression is used
+String ciFriendlyPropertyName =
+
AbstractRewritePomsPhase.extractPropertyFromExpression(versionElement.getTextNormalize());
+Properties properties = getProperties();
+if (properties != null) {
+properties.computeIfPresent(ciFriendlyPropertyName, (k, v) 
-> version);

Review Comment:
   Unimplemented (stub) method call, it does nothing.



-- 
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] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791299#comment-17791299
 ] 

ASF GitHub Bot commented on MRELEASE-1109:
--

mkolesnikov commented on code in PR #198:
URL: https://github.com/apache/maven-release/pull/198#discussion_r1409822004


##
maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModel.java:
##
@@ -189,7 +192,17 @@ public void setVersion(String version) {
 project.addContent(index + 2, versionElement);
 }
 } else {
-JDomUtils.rewriteValue(versionElement, version);
+if 
(AbstractRewritePomsPhase.isCiFriendlyVersion(versionElement.getTextNormalize()))
 {
+// try to rewrite property if CI friendly expression is used
+String ciFriendlyPropertyName =
+
AbstractRewritePomsPhase.extractPropertyFromExpression(versionElement.getTextNormalize());
+Properties properties = getProperties();
+if (properties != null) {
+properties.computeIfPresent(ciFriendlyPropertyName, (k, v) 
-> version);

Review Comment:
   Unimplemented (stub) method call, it does nothing.





> update-versions removes the CI-friendly ${revisions}
> 
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per 
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
>   ${revision}
>   ...
>   
>     1.0.0-SNAPSHOT
>   
> {code}
> If I run {{mvn release:update-versions}} (with or without 
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change 
> the {{$revision}} property. Instead it blindly replaces 
> {{${revision}}} with the hard-coded version set on the CLI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] [MRELEASE-1109] Support CI friendly versions [maven-release]

[via GitHub]

mkolesnikov commented on code in PR #198:
URL: https://github.com/apache/maven-release/pull/198#discussion_r1409835601


##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -89,6 +92,18 @@ public abstract class AbstractRewritePomsPhase extends 
AbstractReleasePhase impl
  */
 private String modelETL = JDomModelETLFactory.NAME;
 
+/**
+ * Regular expression pattern matching Maven expressions (i.e. references 
to Maven properties).
+ * The first group selects the property name the expression refers to.
+ */
+private static final Pattern EXPRESSION_PATTERN = 
Pattern.compile("\\$\\{(.+)\\}");

Review Comment:
   Would fail in case of `${revision}${sha1}${changelist}`, 
looks like the `revision` the only property from CI Friendly is supported right 
now.



-- 
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] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791304#comment-17791304
 ] 

ASF GitHub Bot commented on MRELEASE-1109:
--

mkolesnikov commented on code in PR #198:
URL: https://github.com/apache/maven-release/pull/198#discussion_r1409835601


##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -89,6 +92,18 @@ public abstract class AbstractRewritePomsPhase extends 
AbstractReleasePhase impl
  */
 private String modelETL = JDomModelETLFactory.NAME;
 
+/**
+ * Regular expression pattern matching Maven expressions (i.e. references 
to Maven properties).
+ * The first group selects the property name the expression refers to.
+ */
+private static final Pattern EXPRESSION_PATTERN = 
Pattern.compile("\\$\\{(.+)\\}");

Review Comment:
   Would fail in case of `${revision}${sha1}${changelist}`, 
looks like the `revision` the only property from CI Friendly is supported right 
now.





> update-versions removes the CI-friendly ${revisions}
> 
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per 
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
>   ${revision}
>   ...
>   
>     1.0.0-SNAPSHOT
>   
> {code}
> If I run {{mvn release:update-versions}} (with or without 
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change 
> the {{$revision}} property. Instead it blindly replaces 
> {{${revision}}} with the hard-coded version set on the CLI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[PR] MRELEASE-1109 patch JDomModel [maven-release]

[via GitHub]

mkolesnikov opened a new pull request, #201:
URL: https://github.com/apache/maven-release/pull/201

   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/MRELEASE) 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 `[MRELEASE-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MRELEASE-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 verify -Prun-its` to make sure basic checks pass. A 
more thorough check will 
  be performed on your pull request automatically.
   
   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] [Commented] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791311#comment-17791311
 ] 

ASF GitHub Bot commented on MRELEASE-1109:
--

mkolesnikov opened a new pull request, #201:
URL: https://github.com/apache/maven-release/pull/201

   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/MRELEASE) 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 `[MRELEASE-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MRELEASE-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 verify -Prun-its` to make sure basic checks pass. A 
more thorough check will 
  be performed on your pull request automatically.
   
   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).
   
   




> update-versions removes the CI-friendly ${revisions}
> 
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per 
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
>   ${revision}
>   ...
>   
>     1.0.0-SNAPSHOT
>   
> {code}
> If I run {{mvn release:update-versions}} (with or without 
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change 
> the {{$revision}} property. Instead it blindly replaces 
> {{${revision}}} with the hard-coded version set on the CLI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] [MRELEASE-1109] Support CI friendly versions [maven-release]

[via GitHub]

mkolesnikov commented on code in PR #198:
URL: https://github.com/apache/maven-release/pull/198#discussion_r1409843204


##
maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModel.java:
##
@@ -189,7 +192,17 @@ public void setVersion(String version) {
 project.addContent(index + 2, versionElement);
 }
 } else {
-JDomUtils.rewriteValue(versionElement, version);
+if 
(AbstractRewritePomsPhase.isCiFriendlyVersion(versionElement.getTextNormalize()))
 {
+// try to rewrite property if CI friendly expression is used
+String ciFriendlyPropertyName =
+
AbstractRewritePomsPhase.extractPropertyFromExpression(versionElement.getTextNormalize());
+Properties properties = getProperties();
+if (properties != null) {
+properties.computeIfPresent(ciFriendlyPropertyName, (k, v) 
-> version);

Review Comment:
   https://github.com/apache/maven-release/pull/201



-- 
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] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791312#comment-17791312
 ] 

ASF GitHub Bot commented on MRELEASE-1109:
--

mkolesnikov commented on code in PR #198:
URL: https://github.com/apache/maven-release/pull/198#discussion_r1409843204


##
maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModel.java:
##
@@ -189,7 +192,17 @@ public void setVersion(String version) {
 project.addContent(index + 2, versionElement);
 }
 } else {
-JDomUtils.rewriteValue(versionElement, version);
+if 
(AbstractRewritePomsPhase.isCiFriendlyVersion(versionElement.getTextNormalize()))
 {
+// try to rewrite property if CI friendly expression is used
+String ciFriendlyPropertyName =
+
AbstractRewritePomsPhase.extractPropertyFromExpression(versionElement.getTextNormalize());
+Properties properties = getProperties();
+if (properties != null) {
+properties.computeIfPresent(ciFriendlyPropertyName, (k, v) 
-> version);

Review Comment:
   https://github.com/apache/maven-release/pull/201





> update-versions removes the CI-friendly ${revisions}
> 
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per 
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
>   ${revision}
>   ...
>   
>     1.0.0-SNAPSHOT
>   
> {code}
> If I run {{mvn release:update-versions}} (with or without 
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change 
> the {{$revision}} property. Instead it blindly replaces 
> {{${revision}}} with the hard-coded version set on the CLI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[PR] [MRELEASE-1109] Snapshot detection and support for versions like `${revision}${sha1}${changelist}` [maven-release]

[via GitHub]

mkolesnikov opened a new pull request, #202:
URL: https://github.com/apache/maven-release/pull/202

   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/MRELEASE) 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 `[MRELEASE-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MRELEASE-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 verify -Prun-its` to make sure basic checks pass. A 
more thorough check will 
  be performed on your pull request automatically.
   
   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] [Commented] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791315#comment-17791315
 ] 

ASF GitHub Bot commented on MRELEASE-1109:
--

mkolesnikov opened a new pull request, #202:
URL: https://github.com/apache/maven-release/pull/202

   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/MRELEASE) 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 `[MRELEASE-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MRELEASE-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 verify -Prun-its` to make sure basic checks pass. A 
more thorough check will 
  be performed on your pull request automatically.
   
   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).
   
   




> update-versions removes the CI-friendly ${revisions}
> 
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per 
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
>   ${revision}
>   ...
>   
>     1.0.0-SNAPSHOT
>   
> {code}
> If I run {{mvn release:update-versions}} (with or without 
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change 
> the {{$revision}} property. Instead it blindly replaces 
> {{${revision}}} with the hard-coded version set on the CLI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791316#comment-17791316
 ] 

ASF GitHub Bot commented on MRELEASE-1109:
--

mkolesnikov commented on code in PR #198:
URL: https://github.com/apache/maven-release/pull/198#discussion_r1409846744


##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -89,6 +92,18 @@ public abstract class AbstractRewritePomsPhase extends 
AbstractReleasePhase impl
  */
 private String modelETL = JDomModelETLFactory.NAME;
 
+/**
+ * Regular expression pattern matching Maven expressions (i.e. references 
to Maven properties).
+ * The first group selects the property name the expression refers to.
+ */
+private static final Pattern EXPRESSION_PATTERN = 
Pattern.compile("\\$\\{(.+)\\}");

Review Comment:
   https://github.com/apache/maven-release/pull/202





> update-versions removes the CI-friendly ${revisions}
> 
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per 
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
>   ${revision}
>   ...
>   
>     1.0.0-SNAPSHOT
>   
> {code}
> If I run {{mvn release:update-versions}} (with or without 
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change 
> the {{$revision}} property. Instead it blindly replaces 
> {{${revision}}} with the hard-coded version set on the CLI.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] [MRELEASE-1109] Support CI friendly versions [maven-release]

[via GitHub]

mkolesnikov commented on code in PR #198:
URL: https://github.com/apache/maven-release/pull/198#discussion_r1409846744


##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -89,6 +92,18 @@ public abstract class AbstractRewritePomsPhase extends 
AbstractReleasePhase impl
  */
 private String modelETL = JDomModelETLFactory.NAME;
 
+/**
+ * Regular expression pattern matching Maven expressions (i.e. references 
to Maven properties).
+ * The first group selects the property name the expression refers to.
+ */
+private static final Pattern EXPRESSION_PATTERN = 
Pattern.compile("\\$\\{(.+)\\}");

Review Comment:
   https://github.com/apache/maven-release/pull/202



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] [MCOMPILER-381] - Refactor incremental detection [maven-compiler-plugin]

[via GitHub]

jorsol commented on code in PR #181:
URL: 
https://github.com/apache/maven-compiler-plugin/pull/181#discussion_r1406583464


##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -876,37 +874,33 @@ public void execute() throws MojoExecutionException, 
CompilationFailureException
 
 incrementalBuildHelperRequest = new 
IncrementalBuildHelperRequest().inputFiles(sources);
 
-DirectoryScanResult dsr = 
computeInputFileTreeChanges(incrementalBuildHelper, sources);
-
-boolean immutableOutputFile = compiler.getCompilerOutputStyle()
-
.equals(CompilerOutputStyle.ONE_OUTPUT_FILE_FOR_ALL_INPUT_FILES)
-&& !canUpdateTarget;
-boolean dependencyChanged = isDependencyChanged();
-boolean sourceChanged = isSourceChanged(compilerConfiguration, 
compiler);
-boolean inputFileTreeChanged = hasInputFileTreeChanged(dsr);
-// CHECKSTYLE_OFF: LineLength
-if (immutableOutputFile || dependencyChanged || sourceChanged 
|| inputFileTreeChanged)
-// CHECKSTYLE_ON: LineLength
-{
-String cause = immutableOutputFile
-? "immutable single output file"
-: (dependencyChanged
-? "changed dependency"
-: (sourceChanged ? "changed source code" : 
"added or removed source files"));
-getLog().info("Recompiling the module because of " + cause 
+ ".");
-if (showCompilationChanges) {
-for (String fileAdded : dsr.getFilesAdded()) {
-getLog().info("\t+ " + fileAdded);
-}
-for (String fileRemoved : dsr.getFilesRemoved()) {
-getLog().info("\t- " + fileRemoved);
-}
-}
-
+// Strategies used to detect modifications.
+Supplier immutableOutputFile = () -> 
(compiler.getCompilerOutputStyle()
+
.equals(CompilerOutputStyle.ONE_OUTPUT_FILE_FOR_ALL_INPUT_FILES)
+&& !canUpdateTarget)
+? "immutable single output file"
+: null;
+Supplier dependencyChanged = () -> 
isDependencyChanged() ? "changed dependency" : null;
+Supplier sourceChanged =
+() -> isSourceChanged(compilerConfiguration, compiler) 
? "changed source code" : null;
+Supplier inputFileTreeChanged =
+() -> 
hasInputFileTreeChanged(computeInputFileTreeChanges(incrementalBuildHelper, 
sources))
+? "added or removed source files"
+: null;
+
+// Lazy evaluation of the incremental compilation detection.
+String cause = Stream.of(immutableOutputFile, 
dependencyChanged, sourceChanged, inputFileTreeChanged)

Review Comment:
   Will need to undo the lazy evaluation, I plan to make more changes to the 
dependency detection and I need to store the status of the detection, if I 
lazily run this it will not execute and store the file and that means that the 
next execution could be recompiled again. 😞 Also the inputFileTreeChanged is 
affected since this already stores the state of files, running this lazily will 
just postpone the run in a second or third run.



-- 
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-381) Refactoring needed for isDependencyChanged / Using fileExtensions (AbstractCompilerMojo)

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791321#comment-17791321
 ] 

ASF GitHub Bot commented on MCOMPILER-381:
--

jorsol commented on code in PR #181:
URL: 
https://github.com/apache/maven-compiler-plugin/pull/181#discussion_r1406583464


##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -876,37 +874,33 @@ public void execute() throws MojoExecutionException, 
CompilationFailureException
 
 incrementalBuildHelperRequest = new 
IncrementalBuildHelperRequest().inputFiles(sources);
 
-DirectoryScanResult dsr = 
computeInputFileTreeChanges(incrementalBuildHelper, sources);
-
-boolean immutableOutputFile = compiler.getCompilerOutputStyle()
-
.equals(CompilerOutputStyle.ONE_OUTPUT_FILE_FOR_ALL_INPUT_FILES)
-&& !canUpdateTarget;
-boolean dependencyChanged = isDependencyChanged();
-boolean sourceChanged = isSourceChanged(compilerConfiguration, 
compiler);
-boolean inputFileTreeChanged = hasInputFileTreeChanged(dsr);
-// CHECKSTYLE_OFF: LineLength
-if (immutableOutputFile || dependencyChanged || sourceChanged 
|| inputFileTreeChanged)
-// CHECKSTYLE_ON: LineLength
-{
-String cause = immutableOutputFile
-? "immutable single output file"
-: (dependencyChanged
-? "changed dependency"
-: (sourceChanged ? "changed source code" : 
"added or removed source files"));
-getLog().info("Recompiling the module because of " + cause 
+ ".");
-if (showCompilationChanges) {
-for (String fileAdded : dsr.getFilesAdded()) {
-getLog().info("\t+ " + fileAdded);
-}
-for (String fileRemoved : dsr.getFilesRemoved()) {
-getLog().info("\t- " + fileRemoved);
-}
-}
-
+// Strategies used to detect modifications.
+Supplier immutableOutputFile = () -> 
(compiler.getCompilerOutputStyle()
+
.equals(CompilerOutputStyle.ONE_OUTPUT_FILE_FOR_ALL_INPUT_FILES)
+&& !canUpdateTarget)
+? "immutable single output file"
+: null;
+Supplier dependencyChanged = () -> 
isDependencyChanged() ? "changed dependency" : null;
+Supplier sourceChanged =
+() -> isSourceChanged(compilerConfiguration, compiler) 
? "changed source code" : null;
+Supplier inputFileTreeChanged =
+() -> 
hasInputFileTreeChanged(computeInputFileTreeChanges(incrementalBuildHelper, 
sources))
+? "added or removed source files"
+: null;
+
+// Lazy evaluation of the incremental compilation detection.
+String cause = Stream.of(immutableOutputFile, 
dependencyChanged, sourceChanged, inputFileTreeChanged)

Review Comment:
   Will need to undo the lazy evaluation, I plan to make more changes to the 
dependency detection and I need to store the status of the detection, if I 
lazily run this it will not execute and store the file and that means that the 
next execution could be recompiled again. 😞 Also the inputFileTreeChanged is 
affected since this already stores the state of files, running this lazily will 
just postpone the run in a second or third run.





> Refactoring needed for isDependencyChanged / Using fileExtensions 
> (AbstractCompilerMojo)
> 
>
> Key: MCOMPILER-381
> URL: https://issues.apache.org/jira/browse/MCOMPILER-381
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.12.0
>
>
> The code in the class AbstractCompilerMojo has a method 
> {{isDependencyChanged}} which uses the attribute {{fileExtensions}} which is 
> being changed within the {{isDependencyChanged}} method. This attribute is 
> also being used by the method {{hasNewFile}} which is a kind of confusing (a 
> control via a global variable).
> Furthermore a change in {{isDependencyChanged}} where replacing {{".class"}} 
> with {{"class"}} results in a [fail which is described here|MCOMPILER-379]. 
> It should be investigated how this code can be made more c

[jira] [Assigned] (MRESOLVER-445) Introduce MutableSession, a common ancestor for build and def impl

[Tamas Cservenak (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak reassigned MRESOLVER-445:
-

Assignee: Tamas Cservenak

> Introduce MutableSession, a common ancestor for build and def impl
> --
>
> Key: MRESOLVER-445
> URL: https://issues.apache.org/jira/browse/MRESOLVER-445
> Project: Maven Resolver
>  Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Reason is that this would simplify existing codebase upgrades, no need to 
> maintain two execution paths.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[PR] Bump ch.qos.logback:logback-classic from 1.2.11 to 1.3.12 [maven]

[via GitHub]

dependabot[bot] opened a new pull request, #1329:
URL: https://github.com/apache/maven/pull/1329

   Bumps [ch.qos.logback:logback-classic](https://github.com/qos-ch/logback) 
from 1.2.11 to 1.3.12.
   
   Commits
   
   https://github.com/qos-ch/logback/commit/0df4ec15d45301b5d0a6e2de6466a17944c3a871";>0df4ec1
 prepare release 1.3.12
   https://github.com/qos-ch/logback/commit/189af5029addc72c91300e3e53466de5a1ca9894";>189af50
 ensure JDK 8 compatibility
   https://github.com/qos-ch/logback/commit/14a71d02102bc5365398ff388cee065eb99ce141";>14a71d0
 cater for array size marked with -1
   https://github.com/qos-ch/logback/commit/b8eac23a9de9e05fb6d51160b3f46acd91af9731";>b8eac23
 prevent DOS attacks using on malicious serialized input
   https://github.com/qos-ch/logback/commit/d87dd1221eb23732f4400cb60de725765539a274";>d87dd12
 further support for Virtual threads, issues 737
   https://github.com/qos-ch/logback/commit/034aaee06785b817d41807ea756ce765ed9c8fb3";>034aaee
 add support for Virtual threads
   https://github.com/qos-ch/logback/commit/d6294e579848e5c3cd179d495c3c668d5c642f32";>d6294e5
 parameterizable invocation gate delay
   https://github.com/qos-ch/logback/commit/3b91f6d5137814b89a7c9277279ca630292f17c2";>3b91f6d
 minor refactoring
   https://github.com/qos-ch/logback/commit/d94ebec6edfdd6e7e3737e9e4c3cd1551e8cdec0";>d94ebec
 fix guthub issue 715
   https://github.com/qos-ch/logback/commit/c76b3030ce618b8c361f39c09779b0a738baf8a6";>c76b303
 minor refactoring for better readability
   Additional commits viewable in https://github.com/qos-ch/logback/compare/v_1.2.11...v_1.3.12";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=ch.qos.logback:logback-classic&package-manager=maven&previous-version=1.2.11&new-version=1.3.12)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot show  ignore conditions` will show all of 
the ignore conditions of the specified dependency
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   You can disable automated security fix PRs for this repo from the [Security 
Alerts page](https://github.com/apache/maven/network/alerts).
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[PR] Bump ch.qos.logback:logback-classic from 1.2.3 to 1.3.12 in /surefire-its/src/test/resources/surefire-1659-stream-corruption [maven-surefire]

[via GitHub]

dependabot[bot] opened a new pull request, #691:
URL: https://github.com/apache/maven-surefire/pull/691

   Bumps [ch.qos.logback:logback-classic](https://github.com/qos-ch/logback) 
from 1.2.3 to 1.3.12.
   
   Commits
   
   https://github.com/qos-ch/logback/commit/0df4ec15d45301b5d0a6e2de6466a17944c3a871";>0df4ec1
 prepare release 1.3.12
   https://github.com/qos-ch/logback/commit/189af5029addc72c91300e3e53466de5a1ca9894";>189af50
 ensure JDK 8 compatibility
   https://github.com/qos-ch/logback/commit/14a71d02102bc5365398ff388cee065eb99ce141";>14a71d0
 cater for array size marked with -1
   https://github.com/qos-ch/logback/commit/b8eac23a9de9e05fb6d51160b3f46acd91af9731";>b8eac23
 prevent DOS attacks using on malicious serialized input
   https://github.com/qos-ch/logback/commit/d87dd1221eb23732f4400cb60de725765539a274";>d87dd12
 further support for Virtual threads, issues 737
   https://github.com/qos-ch/logback/commit/034aaee06785b817d41807ea756ce765ed9c8fb3";>034aaee
 add support for Virtual threads
   https://github.com/qos-ch/logback/commit/d6294e579848e5c3cd179d495c3c668d5c642f32";>d6294e5
 parameterizable invocation gate delay
   https://github.com/qos-ch/logback/commit/3b91f6d5137814b89a7c9277279ca630292f17c2";>3b91f6d
 minor refactoring
   https://github.com/qos-ch/logback/commit/d94ebec6edfdd6e7e3737e9e4c3cd1551e8cdec0";>d94ebec
 fix guthub issue 715
   https://github.com/qos-ch/logback/commit/c76b3030ce618b8c361f39c09779b0a738baf8a6";>c76b303
 minor refactoring for better readability
   Additional commits viewable in https://github.com/qos-ch/logback/compare/v_1.2.3...v_1.3.12";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=ch.qos.logback:logback-classic&package-manager=maven&previous-version=1.2.3&new-version=1.3.12)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot show  ignore conditions` will show all of 
the ignore conditions of the specified dependency
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   You can disable automated security fix PRs for this repo from the [Security 
Alerts page](https://github.com/apache/maven-surefire/network/alerts).
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[PR] Bump actions/setup-java from 3 to 4 [maven-jlink-plugin]

[via GitHub]

dependabot[bot] opened a new pull request, #173:
URL: https://github.com/apache/maven-jlink-plugin/pull/173

   Bumps [actions/setup-java](https://github.com/actions/setup-java) from 3 to 
4.
   
   Release notes
   Sourced from https://github.com/actions/setup-java/releases";>actions/setup-java's 
releases.
   
   v4.0.0
   What's Changed
   In the scope of this release, the version of the Node.js runtime was 
updated to 20. The majority of dependencies were updated to the latest 
versions. From now on, the code for the setup-java will run on Node.js 20 
instead of Node.js 16.
   Breaking changes
   
   Update Node.js runtime to version 20 by https://github.com/aparnajyothi-y";>@​aparnajyothi-y in 
https://redirect.github.com/actions/setup-java/pull/558";>actions/setup-java#558
   
   Non-breaking changes
   
   Adding support for microsoft openjdk 21.0.0 by https://github.com/ralfstuckert";>@​ralfstuckert in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   Update @​actions/cache dependency and documentation by https://github.com/IvanZosimov";>@​IvanZosimov in https://redirect.github.com/actions/setup-java/pull/549";>actions/setup-java#549
   Implementation of the cache-dependency-path option to control caching 
dependency by https://github.com/itchyny";>@​itchyny 
in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   New Contributors
   
   https://github.com/ralfstuckert";>@​ralfstuckert made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   https://github.com/itchyny";>@​itchyny made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v4.0.0";>https://github.com/actions/setup-java/compare/v3...v4.0.0
   v3.13.0
   What's changed
   In the scope of this release, support for Dragonwell JDK was added by https://github.com/Accelerator1996";>@​Accelerator1996 in 
https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   steps:
- name: Checkout
  uses: actions/checkout@v3
- name: Setup-java
  uses: actions/setup-java@v3
  with:
distribution: 'dragonwell'
java-version: '17'
   
   Several inaccuracies were also fixed:
   
   Fix XML namespaces wrongly using https by https://github.com/gnodet";>@​gnodet in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   Fix typo and remove unintentional(?) word by https://github.com/CyberFlameGO";>@​CyberFlameGO in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   Fix usage link within the README.md file by https://github.com/dassiorleando";>@​dassiorleando in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   
   New Contributors
   
   https://github.com/CyberFlameGO";>@​CyberFlameGO made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   https://github.com/dassiorleando";>@​dassiorleando made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   https://github.com/gnodet";>@​gnodet made their 
first contribution in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   https://github.com/Accelerator1996";>@​Accelerator1996 
made their first contribution in https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v3.13.0";>https://github.com/actions/setup-java/compare/v3...v3.13.0
   v3.12.0
   
   
   ... (truncated)
   
   
   Commits
   
   https://github.com/actions/setup-java/commit/387ac29b308b003ca37ba93a6cab5eb57c8f5f93";>387ac29
 Upgrade Node to v20 (https://redirect.github.com/actions/setup-java/issues/558";>#558)
   https://github.com/actions/setup-java/commit/9eda6b51cc4f6ee99be3dd5537b85e389e47bda9";>9eda6b5
 feat: implement cache-dependency-path option to control caching dependency 
(#...
   https://github.com/actions/setup-java/commit/78078da0cd035d0d177cc2cb696e05d96fba7d11";>78078da
 Update @​actions/cache dependency and documentation (https://redirect.github.com/actions/setup-java/issues/549";>#549)
   https://github.com/actions/setup-java/commit/5caaba646e214abb5c4c808eb8fe13db519ab757";>5caaba6
 add support for microsoft openjdk 21.0.0 (https://redirect.github.com/actions/setup-java/issues/546";>#546)
   See full diff in https://github.com/actions/setup-java/compare/v3...v4";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/setup-java&package-manager=github_actions&previous-version=3&new-version=4)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-d

Re: [PR] Bump actions/setup-java from 3 to 4 [maven-jlink-plugin]

[via GitHub]

slachiewicz merged PR #173:
URL: https://github.com/apache/maven-jlink-plugin/pull/173


-- 
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 actions/setup-java from 3 to 4 [maven-jlink-plugin]

[via GitHub]

olamy commented on PR #173:
URL: 
https://github.com/apache/maven-jlink-plugin/pull/173#issuecomment-1832881593

   shouldn't we use the shared gh action?


-- 
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-1285] use an up-to-date scanner instead the newscanner [maven-filtering]

[via GitHub]

lalmeras commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1832907067

   Here is a branch with my proposal : 
https://github.com/lalmeras/maven-filtering/commits/MSHARED-1285
   
   * first commit is a test refactor applied to existing master codebase
   * second commit applies @laeubi proposal. I restore original ignoreDelta 
when filters or output directory trigger *hasDelta=true*, as this is an 
expected behaviour from tests
   
   Both commits built with success with java 8 / java 17 / mvn 3.8.
   
   I finally understand why old tests work. It is because they relied only on 
Scanner behavior, and not isUptodate / hasDelta methods. So they accommodate 
nicely with the buggy TestIncrementalBuildContext.
   
   No work done on this issue's testcase. I can work on it if this first 
proposal seems OK.
   
   I do not open another PR; feel free to integrate my proposal in this PR.


-- 
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

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791384#comment-17791384
 ] 

ASF GitHub Bot commented on MSHARED-1285:
-

lalmeras commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1832907067

   Here is a branch with my proposal : 
https://github.com/lalmeras/maven-filtering/commits/MSHARED-1285
   
   * first commit is a test refactor applied to existing master codebase
   * second commit applies @laeubi proposal. I restore original ignoreDelta 
when filters or output directory trigger *hasDelta=true*, as this is an 
expected behaviour from tests
   
   Both commits built with success with java 8 / java 17 / mvn 3.8.
   
   I finally understand why old tests work. It is because they relied only on 
Scanner behavior, and not isUptodate / hasDelta methods. So they accommodate 
nicely with the buggy TestIncrementalBuildContext.
   
   No work done on this issue's testcase. I can work on it if this first 
proposal seems OK.
   
   I do not open another PR; feel free to integrate my proposal in this PR.




> 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
>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)

[PR] Bump actions/setup-java from 3 to 4 [maven-jdeprscan-plugin]

[via GitHub]

dependabot[bot] opened a new pull request, #13:
URL: https://github.com/apache/maven-jdeprscan-plugin/pull/13

   Bumps [actions/setup-java](https://github.com/actions/setup-java) from 3 to 
4.
   
   Release notes
   Sourced from https://github.com/actions/setup-java/releases";>actions/setup-java's 
releases.
   
   v4.0.0
   What's Changed
   In the scope of this release, the version of the Node.js runtime was 
updated to 20. The majority of dependencies were updated to the latest 
versions. From now on, the code for the setup-java will run on Node.js 20 
instead of Node.js 16.
   Breaking changes
   
   Update Node.js runtime to version 20 by https://github.com/aparnajyothi-y";>@​aparnajyothi-y in 
https://redirect.github.com/actions/setup-java/pull/558";>actions/setup-java#558
   
   Non-breaking changes
   
   Adding support for microsoft openjdk 21.0.0 by https://github.com/ralfstuckert";>@​ralfstuckert in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   Update @​actions/cache dependency and documentation by https://github.com/IvanZosimov";>@​IvanZosimov in https://redirect.github.com/actions/setup-java/pull/549";>actions/setup-java#549
   Implementation of the cache-dependency-path option to control caching 
dependency by https://github.com/itchyny";>@​itchyny 
in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   New Contributors
   
   https://github.com/ralfstuckert";>@​ralfstuckert made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   https://github.com/itchyny";>@​itchyny made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v4.0.0";>https://github.com/actions/setup-java/compare/v3...v4.0.0
   v3.13.0
   What's changed
   In the scope of this release, support for Dragonwell JDK was added by https://github.com/Accelerator1996";>@​Accelerator1996 in 
https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   steps:
- name: Checkout
  uses: actions/checkout@v3
- name: Setup-java
  uses: actions/setup-java@v3
  with:
distribution: 'dragonwell'
java-version: '17'
   
   Several inaccuracies were also fixed:
   
   Fix XML namespaces wrongly using https by https://github.com/gnodet";>@​gnodet in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   Fix typo and remove unintentional(?) word by https://github.com/CyberFlameGO";>@​CyberFlameGO in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   Fix usage link within the README.md file by https://github.com/dassiorleando";>@​dassiorleando in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   
   New Contributors
   
   https://github.com/CyberFlameGO";>@​CyberFlameGO made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   https://github.com/dassiorleando";>@​dassiorleando made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   https://github.com/gnodet";>@​gnodet made their 
first contribution in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   https://github.com/Accelerator1996";>@​Accelerator1996 
made their first contribution in https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v3.13.0";>https://github.com/actions/setup-java/compare/v3...v3.13.0
   v3.12.0
   
   
   ... (truncated)
   
   
   Commits
   
   https://github.com/actions/setup-java/commit/387ac29b308b003ca37ba93a6cab5eb57c8f5f93";>387ac29
 Upgrade Node to v20 (https://redirect.github.com/actions/setup-java/issues/558";>#558)
   https://github.com/actions/setup-java/commit/9eda6b51cc4f6ee99be3dd5537b85e389e47bda9";>9eda6b5
 feat: implement cache-dependency-path option to control caching dependency 
(#...
   https://github.com/actions/setup-java/commit/78078da0cd035d0d177cc2cb696e05d96fba7d11";>78078da
 Update @​actions/cache dependency and documentation (https://redirect.github.com/actions/setup-java/issues/549";>#549)
   https://github.com/actions/setup-java/commit/5caaba646e214abb5c4c808eb8fe13db519ab757";>5caaba6
 add support for microsoft openjdk 21.0.0 (https://redirect.github.com/actions/setup-java/issues/546";>#546)
   See full diff in https://github.com/actions/setup-java/compare/v3...v4";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/setup-java&package-manager=github_actions&previous-version=3&new-version=4)](https://docs.github.com/en/github/managing-security-vulnerabilities/about

[PR] Bump actions/setup-java from 3 to 4 [maven-gh-actions-shared]

[via GitHub]

dependabot[bot] opened a new pull request, #84:
URL: https://github.com/apache/maven-gh-actions-shared/pull/84

   Bumps [actions/setup-java](https://github.com/actions/setup-java) from 3 to 
4.
   
   Release notes
   Sourced from https://github.com/actions/setup-java/releases";>actions/setup-java's 
releases.
   
   v4.0.0
   What's Changed
   In the scope of this release, the version of the Node.js runtime was 
updated to 20. The majority of dependencies were updated to the latest 
versions. From now on, the code for the setup-java will run on Node.js 20 
instead of Node.js 16.
   Breaking changes
   
   Update Node.js runtime to version 20 by https://github.com/aparnajyothi-y";>@​aparnajyothi-y in 
https://redirect.github.com/actions/setup-java/pull/558";>actions/setup-java#558
   
   Non-breaking changes
   
   Adding support for microsoft openjdk 21.0.0 by https://github.com/ralfstuckert";>@​ralfstuckert in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   Update @​actions/cache dependency and documentation by https://github.com/IvanZosimov";>@​IvanZosimov in https://redirect.github.com/actions/setup-java/pull/549";>actions/setup-java#549
   Implementation of the cache-dependency-path option to control caching 
dependency by https://github.com/itchyny";>@​itchyny 
in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   New Contributors
   
   https://github.com/ralfstuckert";>@​ralfstuckert made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   https://github.com/itchyny";>@​itchyny made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v4.0.0";>https://github.com/actions/setup-java/compare/v3...v4.0.0
   v3.13.0
   What's changed
   In the scope of this release, support for Dragonwell JDK was added by https://github.com/Accelerator1996";>@​Accelerator1996 in 
https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   steps:
- name: Checkout
  uses: actions/checkout@v3
- name: Setup-java
  uses: actions/setup-java@v3
  with:
distribution: 'dragonwell'
java-version: '17'
   
   Several inaccuracies were also fixed:
   
   Fix XML namespaces wrongly using https by https://github.com/gnodet";>@​gnodet in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   Fix typo and remove unintentional(?) word by https://github.com/CyberFlameGO";>@​CyberFlameGO in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   Fix usage link within the README.md file by https://github.com/dassiorleando";>@​dassiorleando in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   
   New Contributors
   
   https://github.com/CyberFlameGO";>@​CyberFlameGO made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   https://github.com/dassiorleando";>@​dassiorleando made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   https://github.com/gnodet";>@​gnodet made their 
first contribution in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   https://github.com/Accelerator1996";>@​Accelerator1996 
made their first contribution in https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v3.13.0";>https://github.com/actions/setup-java/compare/v3...v3.13.0
   v3.12.0
   
   
   ... (truncated)
   
   
   Commits
   
   https://github.com/actions/setup-java/commit/387ac29b308b003ca37ba93a6cab5eb57c8f5f93";>387ac29
 Upgrade Node to v20 (https://redirect.github.com/actions/setup-java/issues/558";>#558)
   https://github.com/actions/setup-java/commit/9eda6b51cc4f6ee99be3dd5537b85e389e47bda9";>9eda6b5
 feat: implement cache-dependency-path option to control caching dependency 
(#...
   https://github.com/actions/setup-java/commit/78078da0cd035d0d177cc2cb696e05d96fba7d11";>78078da
 Update @​actions/cache dependency and documentation (https://redirect.github.com/actions/setup-java/issues/549";>#549)
   https://github.com/actions/setup-java/commit/5caaba646e214abb5c4c808eb8fe13db519ab757";>5caaba6
 add support for microsoft openjdk 21.0.0 (https://redirect.github.com/actions/setup-java/issues/546";>#546)
   See full diff in https://github.com/actions/setup-java/compare/v3...v4";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/setup-java&package-manager=github_actions&previous-version=3&new-version=4)](https://docs.github.com/en/github/managing-security-vulnerabilities/abou

[PR] Bump actions/setup-java from 3 to 4 [maven-gh-actions-shared]

[via GitHub]

dependabot[bot] opened a new pull request, #85:
URL: https://github.com/apache/maven-gh-actions-shared/pull/85

   Bumps [actions/setup-java](https://github.com/actions/setup-java) from 3 to 
4.
   
   Release notes
   Sourced from https://github.com/actions/setup-java/releases";>actions/setup-java's 
releases.
   
   v4.0.0
   What's Changed
   In the scope of this release, the version of the Node.js runtime was 
updated to 20. The majority of dependencies were updated to the latest 
versions. From now on, the code for the setup-java will run on Node.js 20 
instead of Node.js 16.
   Breaking changes
   
   Update Node.js runtime to version 20 by https://github.com/aparnajyothi-y";>@​aparnajyothi-y in 
https://redirect.github.com/actions/setup-java/pull/558";>actions/setup-java#558
   
   Non-breaking changes
   
   Adding support for microsoft openjdk 21.0.0 by https://github.com/ralfstuckert";>@​ralfstuckert in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   Update @​actions/cache dependency and documentation by https://github.com/IvanZosimov";>@​IvanZosimov in https://redirect.github.com/actions/setup-java/pull/549";>actions/setup-java#549
   Implementation of the cache-dependency-path option to control caching 
dependency by https://github.com/itchyny";>@​itchyny 
in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   New Contributors
   
   https://github.com/ralfstuckert";>@​ralfstuckert made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   https://github.com/itchyny";>@​itchyny made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v4.0.0";>https://github.com/actions/setup-java/compare/v3...v4.0.0
   v3.13.0
   What's changed
   In the scope of this release, support for Dragonwell JDK was added by https://github.com/Accelerator1996";>@​Accelerator1996 in 
https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   steps:
- name: Checkout
  uses: actions/checkout@v3
- name: Setup-java
  uses: actions/setup-java@v3
  with:
distribution: 'dragonwell'
java-version: '17'
   
   Several inaccuracies were also fixed:
   
   Fix XML namespaces wrongly using https by https://github.com/gnodet";>@​gnodet in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   Fix typo and remove unintentional(?) word by https://github.com/CyberFlameGO";>@​CyberFlameGO in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   Fix usage link within the README.md file by https://github.com/dassiorleando";>@​dassiorleando in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   
   New Contributors
   
   https://github.com/CyberFlameGO";>@​CyberFlameGO made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   https://github.com/dassiorleando";>@​dassiorleando made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   https://github.com/gnodet";>@​gnodet made their 
first contribution in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   https://github.com/Accelerator1996";>@​Accelerator1996 
made their first contribution in https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v3.13.0";>https://github.com/actions/setup-java/compare/v3...v3.13.0
   v3.12.0
   
   
   ... (truncated)
   
   
   Commits
   
   https://github.com/actions/setup-java/commit/387ac29b308b003ca37ba93a6cab5eb57c8f5f93";>387ac29
 Upgrade Node to v20 (https://redirect.github.com/actions/setup-java/issues/558";>#558)
   https://github.com/actions/setup-java/commit/9eda6b51cc4f6ee99be3dd5537b85e389e47bda9";>9eda6b5
 feat: implement cache-dependency-path option to control caching dependency 
(#...
   https://github.com/actions/setup-java/commit/78078da0cd035d0d177cc2cb696e05d96fba7d11";>78078da
 Update @​actions/cache dependency and documentation (https://redirect.github.com/actions/setup-java/issues/549";>#549)
   https://github.com/actions/setup-java/commit/5caaba646e214abb5c4c808eb8fe13db519ab757";>5caaba6
 add support for microsoft openjdk 21.0.0 (https://redirect.github.com/actions/setup-java/issues/546";>#546)
   See full diff in https://github.com/actions/setup-java/compare/v3...v4";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/setup-java&package-manager=github_actions&previous-version=3&new-version=4)](https://docs.github.com/en/github/managing-security-vulnerabilities/abou

[PR] Bump actions/setup-java from 3 to 4 [maven-gh-actions-shared]

[via GitHub]

dependabot[bot] opened a new pull request, #86:
URL: https://github.com/apache/maven-gh-actions-shared/pull/86

   Bumps [actions/setup-java](https://github.com/actions/setup-java) from 3 to 
4.
   
   Release notes
   Sourced from https://github.com/actions/setup-java/releases";>actions/setup-java's 
releases.
   
   v4.0.0
   What's Changed
   In the scope of this release, the version of the Node.js runtime was 
updated to 20. The majority of dependencies were updated to the latest 
versions. From now on, the code for the setup-java will run on Node.js 20 
instead of Node.js 16.
   Breaking changes
   
   Update Node.js runtime to version 20 by https://github.com/aparnajyothi-y";>@​aparnajyothi-y in 
https://redirect.github.com/actions/setup-java/pull/558";>actions/setup-java#558
   
   Non-breaking changes
   
   Adding support for microsoft openjdk 21.0.0 by https://github.com/ralfstuckert";>@​ralfstuckert in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   Update @​actions/cache dependency and documentation by https://github.com/IvanZosimov";>@​IvanZosimov in https://redirect.github.com/actions/setup-java/pull/549";>actions/setup-java#549
   Implementation of the cache-dependency-path option to control caching 
dependency by https://github.com/itchyny";>@​itchyny 
in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   New Contributors
   
   https://github.com/ralfstuckert";>@​ralfstuckert made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/546";>actions/setup-java#546
   https://github.com/itchyny";>@​itchyny made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/499";>actions/setup-java#499
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v4.0.0";>https://github.com/actions/setup-java/compare/v3...v4.0.0
   v3.13.0
   What's changed
   In the scope of this release, support for Dragonwell JDK was added by https://github.com/Accelerator1996";>@​Accelerator1996 in 
https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   steps:
- name: Checkout
  uses: actions/checkout@v3
- name: Setup-java
  uses: actions/setup-java@v3
  with:
distribution: 'dragonwell'
java-version: '17'
   
   Several inaccuracies were also fixed:
   
   Fix XML namespaces wrongly using https by https://github.com/gnodet";>@​gnodet in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   Fix typo and remove unintentional(?) word by https://github.com/CyberFlameGO";>@​CyberFlameGO in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   Fix usage link within the README.md file by https://github.com/dassiorleando";>@​dassiorleando in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   
   New Contributors
   
   https://github.com/CyberFlameGO";>@​CyberFlameGO made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/518";>actions/setup-java#518
   https://github.com/dassiorleando";>@​dassiorleando made 
their first contribution in https://redirect.github.com/actions/setup-java/pull/525";>actions/setup-java#525
   https://github.com/gnodet";>@​gnodet made their 
first contribution in https://redirect.github.com/actions/setup-java/pull/503";>actions/setup-java#503
   https://github.com/Accelerator1996";>@​Accelerator1996 
made their first contribution in https://redirect.github.com/actions/setup-java/pull/532";>actions/setup-java#532
   
   Full Changelog: https://github.com/actions/setup-java/compare/v3...v3.13.0";>https://github.com/actions/setup-java/compare/v3...v3.13.0
   v3.12.0
   
   
   ... (truncated)
   
   
   Commits
   
   https://github.com/actions/setup-java/commit/387ac29b308b003ca37ba93a6cab5eb57c8f5f93";>387ac29
 Upgrade Node to v20 (https://redirect.github.com/actions/setup-java/issues/558";>#558)
   https://github.com/actions/setup-java/commit/9eda6b51cc4f6ee99be3dd5537b85e389e47bda9";>9eda6b5
 feat: implement cache-dependency-path option to control caching dependency 
(#...
   https://github.com/actions/setup-java/commit/78078da0cd035d0d177cc2cb696e05d96fba7d11";>78078da
 Update @​actions/cache dependency and documentation (https://redirect.github.com/actions/setup-java/issues/549";>#549)
   https://github.com/actions/setup-java/commit/5caaba646e214abb5c4c808eb8fe13db519ab757";>5caaba6
 add support for microsoft openjdk 21.0.0 (https://redirect.github.com/actions/setup-java/issues/546";>#546)
   See full diff in https://github.com/actions/setup-java/compare/v3...v4";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=actions/setup-java&package-manager=github_actions&previous-version=3&new-version=4)](https://docs.github.com/en/github/managing-security-vulnerabilities/abou

Re: [PR] [MSHARED-1285] use an up-to-date scanner instead the newscanner [maven-filtering]

[via GitHub]

laeubi commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1833089113

   > I do not open another PR; feel free to integrate my proposal in this PR.
   
   @lalmeras just open a PR for the testcases I think that can be easier to 
manage also we then have direct PR validation!


-- 
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

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791436#comment-17791436
 ] 

ASF GitHub Bot commented on MSHARED-1285:
-

laeubi commented on PR #77:
URL: https://github.com/apache/maven-filtering/pull/77#issuecomment-1833089113

   > I do not open another PR; feel free to integrate my proposal in this PR.
   
   @lalmeras just open a PR for the testcases I think that can be easier to 
manage also we then have direct PR validation!




> 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
>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-1327] Change output directory default [maven-reporting-impl]

[via GitHub]

kriegaex commented on PR #26:
URL: 
https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1833228927

   @michael-o, the way I understand it, the description applies to what I call 
the _base_ directory, i.e. the `${project.reporting.outputDirectory}` in case 
of site generation. AFAIR, that one can also be adjusted, if a user wants to 
change it. In case of stand-alone execution, the default base directory should 
be `${project.build.directory}` so as not to interfere with the site base 
directory. That is the whole point of this PR.
   
   The description IMO says nothing whatsoever about the plugin-specific report 
output directory, e.g. `apidocs` or `surefire-reports`. Those are inside the 
base directories and there is no reason for them not to be adjustable too.
   
   Of course, `outputDirectory` is only relevant for stand-alone execution, 
because otherwise Maven Site determines the base directory. Actually, I see 
nothing in that text contradicting with what I suggested.


-- 
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-1327) Change output directory default in AbstractMavenReport

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791493#comment-17791493
 ] 

ASF GitHub Bot commented on MSHARED-1327:
-

kriegaex commented on PR #26:
URL: 
https://github.com/apache/maven-reporting-impl/pull/26#issuecomment-1833228927

   @michael-o, the way I understand it, the description applies to what I call 
the _base_ directory, i.e. the `${project.reporting.outputDirectory}` in case 
of site generation. AFAIR, that one can also be adjusted, if a user wants to 
change it. In case of stand-alone execution, the default base directory should 
be `${project.build.directory}` so as not to interfere with the site base 
directory. That is the whole point of this PR.
   
   The description IMO says nothing whatsoever about the plugin-specific report 
output directory, e.g. `apidocs` or `surefire-reports`. Those are inside the 
base directories and there is no reason for them not to be adjustable too.
   
   Of course, `outputDirectory` is only relevant for stand-alone execution, 
because otherwise Maven Site determines the base directory. Actually, I see 
nothing in that text contradicting with what I suggested.




> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M13
>
>
> The output directory should default to {{${project.build.directory}}} instead 
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from 
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution, 
> a plugin should not mess with Maven Site's default directory. Imagine a 
> situation in which each module should get its own, self-consistent report 
> when called stand-alone, but the site should contain an aggregate with a 
> different structure or maybe no report from that plugin at all. The default 
> would then pollute the site directory. This is why on the ML I asked you 
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class 
> field by another {{@Parameter}} annotation on a setter in a subclass it is 
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not 
> use the abstract base class, implements the default correctly: build dir for 
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site 
> generation context, the reporting base directory will be set here 
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)