[jira] [Commented] (MRESOLVER-442) New JDK transport JAR mixes classes with different bytecode

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MRESOLVER-442:
--

rmannibucau commented on PR #381:
URL: https://github.com/apache/maven-resolver/pull/381#issuecomment-1829257005

   As mentionned in #374 I think this is the worse of the 3 options we have 
(mjar, all in one -> #374, 2 jars - 1 java8 and 1  java 11 and be it)




> New JDK transport JAR mixes classes with different bytecode
> ---
>
> Key: MRESOLVER-442
> URL: https://issues.apache.org/jira/browse/MRESOLVER-442
> Project: Maven Resolver
>  Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-3
>
>
> And hence is unusable in projects that use Enforcer to enforce highest 
> allowed bytecode (like Maven is).



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

Re: [PR] [MRESOLVER-442] Build JDK transport MR JAR the proper way [maven-resolver]

[via GitHub]

rmannibucau commented on PR #381:
URL: https://github.com/apache/maven-resolver/pull/381#issuecomment-1829257005

   As mentionned in #374 I think this is the worse of the 3 options we have 
(mjar, all in one -> #374, 2 jars - 1 java8 and 1  java 11 and be it)


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

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

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

Re: [PR] Ensure we have a single JDK module [maven-resolver]

[via GitHub]

rmannibucau commented on PR #374:
URL: https://github.com/apache/maven-resolver/pull/374#issuecomment-1829239333

   @cstamas assuming MJAR works and is transparently handled by the *JRE* is 
wrong as I already mentionned. You are just lucky in your tests it was (side 
note: as war classloader was rarely used in (unit) tests, real runtime 
classloader is not too so we should be extremly cautious there). The JRE 
implementation sits in `JarFile` (`java.util.jar.JarFile#getEntry`) so as soon 
as you don't rely on that to locate `.class` binaries you are doomed. A simple 
case where it will not work whereas you can expect it to work is you explode 
your jars in a directory (recall early javaee 6 glassfish times? ;)) but 
basically any classloader not locating the classes with a jar file (think 
zipfile also handled it but no more sure) or using the exact ^^ API (like 
nested jars which preload in mem bytecode for ex) will not work. OSGi which 
pre-explode the zip in another location can have issue depending the impl and 
even EE can have issues depending the classloader itself. So overall I don't 
think it is s
 ane.
   Lastly, MJAR conserves half of the issues you have right now so not sure it 
solves anything.
   
   side note: we should make enforcer evolve to validate META-INF/versions/ 
classes against a defined bytecode cause today you are happy with it cause it 
is not seen but issue exists.


-- 
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 com.diffplug.spotless:spotless-maven-plugin from 2.40.0 to 2.41.0 [maven-parent]

[via GitHub]

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

   Bumps 
[com.diffplug.spotless:spotless-maven-plugin](https://github.com/diffplug/spotless)
 from 2.40.0 to 2.41.0.
   
   Changelog
   Sourced from https://github.com/diffplug/spotless/blob/main/CHANGES.md;>com.diffplug.spotless:spotless-maven-plugin's
 changelog.
   
   [2.41.0] - 2023-08-29
   Added
   
   Add a jsonPatch step to json formatter 
configurations. This allows patching of JSON documents using https://jsonpatch.com;>JSON Patches. (https://redirect.github.com/diffplug/spotless/pull/1753;>#1753)
   Support GJF own import order. (https://redirect.github.com/diffplug/spotless/pull/1780;>#1780)
   
   Fixed
   
   Use latest versions of popular style guides for eslint 
tests to fix failing useEslintXoStandardRules test. (https://redirect.github.com/diffplug/spotless/pull/1761;>#1761, https://redirect.github.com/diffplug/spotless/issues/1756;>#1756)
   Add support for prettier version 3.0.0 and 
newer. (https://redirect.github.com/diffplug/spotless/pull/1760;>#1760, https://redirect.github.com/diffplug/spotless/issues/1751;>#1751)
   Fix npm install calls when npm cache is not up-to-date. (https://redirect.github.com/diffplug/spotless/pull/1760;>#1760, https://redirect.github.com/diffplug/spotless/issues/1750;>#1750)
   
   Changes
   
   Bump default eslint version to latest 8.31.0 
- 8.45.0 (https://redirect.github.com/diffplug/spotless/pull/1761;>#1761)
   Bump default prettier version to latest (v2) 
2.8.1 - 2.8.8. (https://redirect.github.com/diffplug/spotless/pull/1760;>#1760)
   Bump default greclipse version to latest 4.27 
- 4.28. (https://redirect.github.com/diffplug/spotless/pull/1775;>#1775)
   
   
   
   
   Commits
   
   https://github.com/diffplug/spotless/commit/7e574c6159954115ced357f0e5e1f0adcf9e3e24;>7e574c6
 Published lib/2.41.0
   https://github.com/diffplug/spotless/commit/efe6734696ea20a6b7a6c60944eae4ef4c18c845;>efe6734
 Bump GrEclipse to latest (https://redirect.github.com/diffplug/spotless/issues/1775;>#1775)
   https://github.com/diffplug/spotless/commit/c23f89b5f01c2f8366ef127665351bc83bf10bd7;>c23f89b
 Update changelogs.
   https://github.com/diffplug/spotless/commit/130402a11da098e6e02fc920c8836cad3322348c;>130402a
 Merge branch 'main' into patch-2
   https://github.com/diffplug/spotless/commit/4b1a75b60aa60659422175d9f2576867249319d9;>4b1a75b
 Fix changelog link formats (https://redirect.github.com/diffplug/spotless/issues/1789;>#1789)
   https://github.com/diffplug/spotless/commit/83aace9d39b7037a430945e152b72580797c2a8a;>83aace9
 Fix changelog link formats
   https://github.com/diffplug/spotless/commit/5976175484aa374c4742c83759ee2a5c54a670a6;>5976175
 Check if EditorConfig file exist for Ktlint (https://redirect.github.com/diffplug/spotless/issues/1788;>#1788 
fixes https://redirect.github.com/diffplug/spotless/issues/1785;>#1785)
   https://github.com/diffplug/spotless/commit/62a957e51b723b3572bbe4beef9255e910d9c036;>62a957e
 Categorize as fix rather than new feature.
   https://github.com/diffplug/spotless/commit/b3c59f7d4b9e214c3f4c14d9333b816e3a90a34b;>b3c59f7
 Fix on windows.
   https://github.com/diffplug/spotless/commit/959fd854c36080caa13123de2089ebcb7396adb4;>959fd85
 Check if EditorConfig file exist for Ktlint
   Additional commits viewable in https://github.com/diffplug/spotless/compare/lib/2.40.0...lib/2.41.0;>compare
 view
   
   
   
   
   
   Most Recent Ignore Conditions Applied to This Pull Request
   
   | Dependency Name | Ignore Conditions |
   | --- | --- |
   | com.diffplug.spotless:spotless-maven-plugin | [>= 2.33.a, < 2.34] |
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=com.diffplug.spotless:spotless-maven-plugin=maven=2.40.0=2.41.0)](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
   - 

[jira] [Comment Edited] (MNG-4917) Profile not active even though it has activeByDefault set to true

[Alexander Kriegisch (Jira)]

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

Alexander Kriegisch edited comment on MNG-4917 at 11/28/23 3:01 AM:


Like others have said before, this mode is basically useless, because
* it does not do at all what a user would expect,
* it is unpredictable.

Please, either fix it (much preferred) or remove it from Maven completely to 
prevent further harm. I cannot imagine any meaningful use case for the current 
"implementation" (double quotes, because I consider it buggy).

*Edit:* If anyone is interested in my current workaround:

{code:xml}

  [1.)

{code}


was (Author: kriegaex):
Like others have said before, this mode is basically useless, because
* it does not do at all what a user would expect,
* it is unpredictable.

Please, either fix it (much preferred) or remove it from Maven completely to 
prevent further harm. I cannot imagine any meaningful use case for the current 
"implementation" (double quotes, because I consider it buggy).

**Edit:** If anyone is interested in my current workaround:

{code:xml}

  [1.)

{code}

> Profile not active even though it has activeByDefault set to true
> -
>
> Key: MNG-4917
> URL: https://issues.apache.org/jira/browse/MNG-4917
> Project: Maven
>  Issue Type: Bug
>  Components: Profiles
>Affects Versions: 3.0, 3.8.5
>Reporter: Benson Margulies
>Priority: Major
> Attachments: pom.xml
>
>
> I've got a parent pom with a profile with 
> true.
> You can retrieve it for yourself via git clone 
> git://git.apache.org/webservices-xmlschema.git.
> The problem is the sourcecheck profile in the parent pom. 
> running mvn -Psourcecheck works as expected, but running without the -P fails 
> to activate the profile.
> the help plugin, I think, has separate problems in this area, or perhaps it's 
> not supposed to look at -P?



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

[jira] [Comment Edited] (MNG-4917) Profile not active even though it has activeByDefault set to true

[Alexander Kriegisch (Jira)]

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

Alexander Kriegisch edited comment on MNG-4917 at 11/28/23 3:00 AM:


Like others have said before, this mode is basically useless, because
* it does not do at all what a user would expect,
* it is unpredictable.

Please, either fix it (much preferred) or remove it from Maven completely to 
prevent further harm. I cannot imagine any meaningful use case for the current 
"implementation" (double quotes, because I consider it buggy).

**Edit:** If anyone is interested in my current workaround:

{code:xml}

  [1.)

{code}


was (Author: kriegaex):
Like others have said before, this mode is basically useless, because
* it does not do at all what a user would expect,
* it is unpredictable.

Please, either fix it (much preferred) or remove it from Maven completely to 
prevent further harm. I cannot imagine any meaningful use case for the current 
"implementation" (double quotes, because I consider it buggy).

> Profile not active even though it has activeByDefault set to true
> -
>
> Key: MNG-4917
> URL: https://issues.apache.org/jira/browse/MNG-4917
> Project: Maven
>  Issue Type: Bug
>  Components: Profiles
>Affects Versions: 3.0, 3.8.5
>Reporter: Benson Margulies
>Priority: Major
> Attachments: pom.xml
>
>
> I've got a parent pom with a profile with 
> true.
> You can retrieve it for yourself via git clone 
> git://git.apache.org/webservices-xmlschema.git.
> The problem is the sourcecheck profile in the parent pom. 
> running mvn -Psourcecheck works as expected, but running without the -P fails 
> to activate the profile.
> the help plugin, I think, has separate problems in this area, or perhaps it's 
> not supposed to look at -P?



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

[jira] [Commented] (MNG-4917) Profile not active even though it has activeByDefault set to true

[Alexander Kriegisch (Jira)]

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

Alexander Kriegisch commented on MNG-4917:
--

Like others have said before, this mode is basically useless, because
* it does not do at all what a user would expect,
* it is unpredictable.

Please, either fix it (much preferred) or remove it from Maven completely to 
prevent further harm. I cannot imagine any meaningful use case for the current 
"implementation" (double quotes, because I consider it buggy).

> Profile not active even though it has activeByDefault set to true
> -
>
> Key: MNG-4917
> URL: https://issues.apache.org/jira/browse/MNG-4917
> Project: Maven
>  Issue Type: Bug
>  Components: Profiles
>Affects Versions: 3.0, 3.8.5
>Reporter: Benson Margulies
>Priority: Major
> Attachments: pom.xml
>
>
> I've got a parent pom with a profile with 
> true.
> You can retrieve it for yourself via git clone 
> git://git.apache.org/webservices-xmlschema.git.
> The problem is the sourcecheck profile in the parent pom. 
> running mvn -Psourcecheck works as expected, but running without the -P fails 
> to activate the profile.
> the help plugin, I think, has separate problems in this area, or perhaps it's 
> not supposed to look at -P?



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

[jira] [Commented] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MNG-7919:
-

gnodet merged PR #1325:
URL: https://github.com/apache/maven/pull/1325




> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
>  Issue Type: Task
>  Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>  Labels: up-for-grabs
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}} 
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the 
> root directory or add the root="true" attribute on the root project's model 
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime: 
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO] 
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in 
> debug mode? I would say report it not only in DEBUG mode.



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

Re: [PR] [MNG-7919] Missing .mvn directory is only reported in DEBUG mode [maven]

[via GitHub]

gnodet merged PR #1325:
URL: https://github.com/apache/maven/pull/1325


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

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

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

[jira] [Closed] (MNG-6036) Allow proper namespace usage for pom.xml

[Guillaume Nodet (Jira)]

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

Guillaume Nodet closed MNG-6036.

Fix Version/s: 4.0.0-alpha-9
 Assignee: Guillaume Nodet
   Resolution: Fixed

> Allow proper namespace usage for pom.xml
> 
>
> Key: MNG-6036
> URL: https://issues.apache.org/jira/browse/MNG-6036
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_40, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"
>Reporter: Roland Huss
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> When I use the following pom.xml in order to allow an XSD for my custom 
> plugin configuration:
> {code:xml}
> http://www.w3.org/2001/XMLSchema-instance;
>  xmlns="http://maven.apache.org/POM/4.0.0;
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/POM/4.0.0;>
> 
> 
>  
>  http://maven.apache.org/POM/4.0.0; 
> xmlns="http://fabric8.io/fabric8-maven-plugin;>
>  .
>  
> 
> 
> 
> {code}
> I get this error:
> {code}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Malformed POM 
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml:
>  Unrecognised tag: 'm:configuration' (position: START_TAG seen 
> ...che.org/POM/4.0.0" xmlns="http://fabric8.io/fabric8-maven-plugin;>... 
> @91:117)  @ 
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml,
>  line 91, column 117
>  @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project io.fabric8:docker-jolokia-demo:0.15-SNAPSHOT 
> (/Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml)
>  has 1 error
> [ERROR] Malformed POM 
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml:
>  Unrecognised tag: 'm:configuration' (position: START_TAG seen 
> ...che.org/POM/4.0.0" xmlns="http://fabric8.io/fabric8-maven-plugin;>... 
> @91:117)  @ 
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml,
>  line 91, column 117 -> [Help 2]
> {code}
> It would be awesome if the XML parser would resolve namespaces properly. Its 
> not about adding namespace features, only for plain XML resolving (each 
> decent XML these days should be able to do this transparently).
> Except for 
> https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
>  I couldn't find any statement when namespaces are supported or tolerated. 
> Are there any plans for this (and maybe also to relax the schema constraints 
> on the {{}} tag)  ?
> See also https://github.com/rhuss/poblano/issues/19 for a use case.



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

[jira] [Commented] (MNG-6036) Allow proper namespace usage for pom.xml

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MNG-6036:
-

gnodet merged PR #1318:
URL: https://github.com/apache/maven/pull/1318




> Allow proper namespace usage for pom.xml
> 
>
> Key: MNG-6036
> URL: https://issues.apache.org/jira/browse/MNG-6036
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_40, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"
>Reporter: Roland Huss
>Priority: Major
>
> When I use the following pom.xml in order to allow an XSD for my custom 
> plugin configuration:
> {code:xml}
> http://www.w3.org/2001/XMLSchema-instance;
>  xmlns="http://maven.apache.org/POM/4.0.0;
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/POM/4.0.0;>
> 
> 
>  
>  http://maven.apache.org/POM/4.0.0; 
> xmlns="http://fabric8.io/fabric8-maven-plugin;>
>  .
>  
> 
> 
> 
> {code}
> I get this error:
> {code}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Malformed POM 
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml:
>  Unrecognised tag: 'm:configuration' (position: START_TAG seen 
> ...che.org/POM/4.0.0" xmlns="http://fabric8.io/fabric8-maven-plugin;>... 
> @91:117)  @ 
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml,
>  line 91, column 117
>  @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project io.fabric8:docker-jolokia-demo:0.15-SNAPSHOT 
> (/Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml)
>  has 1 error
> [ERROR] Malformed POM 
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml:
>  Unrecognised tag: 'm:configuration' (position: START_TAG seen 
> ...che.org/POM/4.0.0" xmlns="http://fabric8.io/fabric8-maven-plugin;>... 
> @91:117)  @ 
> /Users/roland/Development/docker/docker-maven-plugin/samples/data-jolokia-demo/pom.xml,
>  line 91, column 117 -> [Help 2]
> {code}
> It would be awesome if the XML parser would resolve namespaces properly. Its 
> not about adding namespace features, only for plain XML resolving (each 
> decent XML these days should be able to do this transparently).
> Except for 
> https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
>  I couldn't find any statement when namespaces are supported or tolerated. 
> Are there any plans for this (and maybe also to relax the schema constraints 
> on the {{}} tag)  ?
> See also https://github.com/rhuss/poblano/issues/19 for a use case.



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

Re: [PR] [MNG-6036] Add namespace to XmlNode [maven]

[via GitHub]

gnodet merged PR #1318:
URL: https://github.com/apache/maven/pull/1318


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

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

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

[PR] Bump org.jsoup:jsoup from 1.16.2 to 1.17.1 [maven-dependency-plugin]

[via GitHub]

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

   Bumps [org.jsoup:jsoup](https://github.com/jhy/jsoup) from 1.16.2 to 1.17.1.
   
   Release notes
   Sourced from https://github.com/jhy/jsoup/releases;>org.jsoup:jsoup's 
releases.
   
   jsoup 1.17.1
   
   
   
   
   ... (truncated)
   
   
   Changelog
   Sourced from https://github.com/jhy/jsoup/blob/master/CHANGES;>org.jsoup:jsoup's 
changelog.
   
   jsoup changelog
   Release 1.17.1 [27-Nov-2023]
   
   
   Improvement: in Jsoup.connect(), added support for request-level 
authentication, supporting authentication to
   proxies and to servers.
   https://redirect.github.com/jhy/jsoup/pull/2046;>jhy/jsoup#2046
   
   
   Improvement: in the Elements list, added direct support for 
#set(index, element), #remove(index),
   #remove(object), #clear(), 
#removeAll(collection), #retainAll(collection), 
#removeIf(filter),
   #replaceAll(operator). These methods update the original DOM, 
as well as the Elements list.
   https://redirect.github.com/jhy/jsoup/pull/2017;>jhy/jsoup#2017
   
   
   Improvement: added the NodeIterator class, to efficiently traverse a node 
tree using the Iterator interface. And
   added Stream Element#stream() and Node#nodeStream() methods, to enable 
fluent composable stream pipelines of node
   traversals.
   https://redirect.github.com/jhy/jsoup/pull/2051;>jhy/jsoup#2051
   
   
   Improvement: when changing the OutputSettings syntax to XML, the xhtml 
EscapeMode is automatically set by default.
   
   
   Improvement: added the :is(selector list) pseudo-selector, 
which finds elements that match any of the selectors in
   the selector list. Useful for making large ORed selectors more readable.
   
   
   Improvement: repackaged the library with native (vs automatic) JPMS 
module support.
   https://redirect.github.com/jhy/jsoup/pull/2025;>jhy/jsoup#2025
   
   
   Improvement: better fidelity of source positions when tracking is 
enabled. And implicitly created or closed elements
   are tracked and detectable via Range.isImplicit().
   https://redirect.github.com/jhy/jsoup/pull/2056;>jhy/jsoup#2056
   
   
   Improvement: when source tracking is enabled, the source position for 
attribute names and values is now available.
   Attribute#sourceRange() provides the ranges.
   https://redirect.github.com/jhy/jsoup/pull/2057;>jhy/jsoup#2057
   
   
   Improvement: when running concurrently under Java 21+ Virtual Threads, 
virtual threads could be pinned to their
   carrier platform thread when parsing an input stream. To improve 
performance, particularly when parsing fetched
   URLs, the internal ConstrainableInputStream has been replaced by 
ControllableInputStream, which avoids the locking
   which caused that pinning.
   https://redirect.github.com/jhy/jsoup/issues/2054;>jhy/jsoup#2054
   
   
   Improvement: in Jsoup.Connect, allow any XML mimetype as a supported 
mimetype. Was previously limited to
   {application|text}/xml. This enables for e.g. fetching SVGs 
with a image/svg+xml mimetype, without having to
   disable mimetype validation.
   https://redirect.github.com/jhy/jsoup/issues/2059;>jhy/jsoup#2059
   
   
   Bugfix: when outputting with XML syntax, HTML elements that were parsed 
as data nodes ( and ) should
   be emitted as CDATA nodes, so that they can be parsed correctly by an XML 
parser.
   https://redirect.github.com/jhy/jsoup/pull/1720;>jhy/jsoup#1720
   
   
   Bugfix: the Immediate Parent selector  could match 
elements above the root context element, causing incorrect
   elements to be returned when used on elements other than the root 
document.
   
   
   
   
   ... (truncated)
   
   
   Commits
   
   https://github.com/jhy/jsoup/commit/8eecef379d5c5af27a9a438fdfce82460e44f08b;>8eecef3
 [maven-release-plugin] prepare release jsoup-1.17.1
   https://github.com/jhy/jsoup/commit/a6c195080466bb3cb7c5a4527622b8f49c7639ad;>a6c1950
 In javadoc, emit links to source
   https://github.com/jhy/jsoup/commit/00f85a826668e5dc1e7b180bba52f35ccb9dbaaf;>00f85a8
 Revised Connection.data javadoc
   https://github.com/jhy/jsoup/commit/f49dd2c7134b23a6c8f72030ef581bb1098c8576;>f49dd2c
 PR url
   https://github.com/jhy/jsoup/commit/4b91adf9a4afb4eaf0e815c48b5d2cfdcb639f66;>4b91adf
 Simpler empty test
   https://github.com/jhy/jsoup/commit/73d450657932370e516f205537b395d1d055d043;>73d4506
 Refactored UserData to be tucked into a hash (https://redirect.github.com/jhy/jsoup/issues/2060;>#2060)
   https://github.com/jhy/jsoup/commit/58521a45067f5c4fa558cb090480fa4b2e407056;>58521a4
 Allow any XML mimetype in Connection
   https://github.com/jhy/jsoup/commit/bc798109ea212dc6117a31c114a0b3641d2658a5;>bc79810
 Specify overrides
   https://github.com/jhy/jsoup/commit/0a737674a52c5cda41aff7a58154d4073fcd3d6c;>0a73767
 Re-specify IteratorAttribute type
   https://github.com/jhy/jsoup/commit/4669e14039a976644e8fcd53bed422b11d32dfeb;>4669e14
 Make Attributes 

[jira] [Updated] (MRESOLVER-321) Resolver while collecting may end up in busy loop without any possibility to be stopped

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-321:
--
Fix Version/s: 2.0.0-alpha-3

> Resolver while collecting may end up in busy loop without any possibility to 
> be stopped
> ---
>
> Key: MRESOLVER-321
> URL: https://issues.apache.org/jira/browse/MRESOLVER-321
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-3
>
>
> As reported by users, under some conditions (MRESOLVER-316) resolver is able 
> to spin itself into busy loop, without possibility to stop it (ie. by 
> interrupting the thread of it).
> Example report: [https://github.com/apache/maven-resolver/pull/236]
> The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the 
> demo code and the diff for it).
> While the PR proposes a code change, that is not covering all, as in case of 
> MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
> visiting DependencyNodes).
> Solutiom: make collector but also visitor sense thread interruption.



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

[jira] [Updated] (MRESOLVER-429) Enhance JDK transport error messaging

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-429:
--
Fix Version/s: 2.0.0-alpha-3

> Enhance JDK transport error messaging
> -
>
> Key: MRESOLVER-429
> URL: https://issues.apache.org/jira/browse/MRESOLVER-429
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-3
>
>
> Currently we rely fully on JDK HttpClient error message for example in case 
> of connection refused: message is "ConnectException", just that. We could 
> improve this, make it more humane.



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

[jira] [Updated] (MRESOLVER-434) Upgrade Parent to 41

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-434:
--
Fix Version/s: 2.0.0-alpha-3

> Upgrade Parent to 41
> 
>
> Key: MRESOLVER-434
> URL: https://issues.apache.org/jira/browse/MRESOLVER-434
> Project: Maven Resolver
>  Issue Type: Dependency upgrade
>  Components: Resolver
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 2.0.0, 1.9.17, 2.0.0-alpha-3
>
>




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

[jira] [Updated] (MRESOLVER-437) Resolver should not override given HTTP transport default use of expect-continue handshake

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-437:
--
Fix Version/s: 2.0.0-alpha-3

> Resolver should not override given HTTP transport default use of 
> expect-continue handshake
> --
>
> Key: MRESOLVER-437
> URL: https://issues.apache.org/jira/browse/MRESOLVER-437
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.18, 2.0.0-alpha-3
>
>
> Resolver should ALLOW to turn ON or OFF the use of Expect-Continue handshake 
> of given HTTP transport, but should forcefully set this on clients. Current 
> master contains "force ON" as Apache HTTP transport uses it, but it does not 
> mean that any other HTTP transport MUST ENABLE it, leave default with room 
> for users to override defaults instead.
> Moreover, due https://bugs.openjdk.org/browse/JDK-8286171 the Expect-Continue 
> config for "jdk" transport below Java 20 should be simply ignored.



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

[jira] [Updated] (MRESOLVER-438) The new jdk transport bug on Java 11 and Java 17

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-438:
--
Fix Version/s: 2.0.0-alpha-3

> The new jdk transport bug on Java 11 and Java 17
> 
>
> Key: MRESOLVER-438
> URL: https://issues.apache.org/jira/browse/MRESOLVER-438
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-3
>
>
> There is this issue (also see related PR, this is NOT only issue when http/2 
> is used, but also when http/1.1 is) 
> https://bugs.openjdk.org/browse/JDK-8286171 that affects all Java versions 
> before Java 20.
> Simply put, jdk transport may hang forever when Expect-Continue handshake is 
> used with it, and remote server does not follow RFC by the letter.
> Fix: on Java versions lower than Java20 simply _ignore_ the expect-continue 
> configuration (do not apply it). Maybe log a warning if user did set it, uses 
> "jdk" transport, but Java version is not 20+



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

[jira] [Updated] (MRESOLVER-436) The Upgrading Resolver page uses classnames before rename

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-436:
--
Fix Version/s: 2.0.0-alpha-3

> The Upgrading Resolver page uses classnames before rename
> -
>
> Key: MRESOLVER-436
> URL: https://issues.apache.org/jira/browse/MRESOLVER-436
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-3
>
>
> The page uses {{CloseableRepositorySystemSession}} while this class has been 
> renamed in 2nd part of MRESOLVER-302



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

[jira] [Updated] (MRESOLVER-372) Sporadic AccessDeniedEx on Windows

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-372:
--
Fix Version/s: 2.0.0-alpha-3

> Sporadic AccessDeniedEx on Windows
> --
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17, 2.0.0-alpha-3
>
>
> Preambulum: original issue is not related to locking at all, is about change 
> done in 1.9 where file processor was altered to use nio2 atomic move. Reason 
> was to prevent possibility of partial download being read by other process 
> (and prevent incomplete files in case of crash). Seems windows (or java on 
> windows) have issues with atomic fs ops, causing sporadic (still unsure why) 
> AccessDeniedExceptions. Below is original issue description as reported:
>  
> {code:java}
>  Caused by: java.nio.file.AccessDeniedException: 
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
>         at 
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
>         at 
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
>         at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
>         at 
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
>         at java.base/java.nio.file.Files.move(Files.java:1432)
>         at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
>         at 
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
>         at 
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
>         at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
>         ... 30 more{code}
>  
> My suggestion would be that resolver simply uses the temp file if it can't be 
> moved to final location and marks it as delete on exit. Even though this is 
> not optimal, it at least ensures the the build does not fail to the cost that 
> next time the file needs to be downloaded again.



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

[jira] [Updated] (MRESOLVER-440) Clean up transport names, configuration properties and documentation

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-440:
--
Fix Version/s: 2.0.0-alpha-3

> Clean up transport names, configuration properties and documentation
> 
>
> Key: MRESOLVER-440
> URL: https://issues.apache.org/jira/browse/MRESOLVER-440
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-3
>
>
> Currently ApacheHC transport is called "http" while JDK transport is called 
> "jdk" and JettyHC is "jetty". Also, historically all transports were 
> connectors, and later was "basic" connector added and transports introduced, 
> but many transport related configuration properties remained as "connector".
> Proposed changes:
>  * Rename ApacheHC to "apache" transport, to "free" the "http" config key. 
> There will be no "http" transport anymore, it is reserved for "shared HTTP 
> related config" that is shared among multiple HTTP transports (apache, jdk, 
> jetty...).
>  * Rename transport specific configurations from "aether.connector.apache..." 
> and "aether.connector.jdk..." to their proper names "aether.transport..."
>  * keep "aether.transport.http..." for generic HTTP protocol related 
> configuration (that may be used by all HTTP using transports).
>  * align many other (for historical reason) badly keyed property to "proper 
> place".
>  * sort out documentation for these, ideally the page should be generated
> As part of this work along with source changes (mostly javadoc) a "tool" has 
> been made that auto-generates this page 
> https://maven.apache.org/resolver/configuration.html



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

[jira] [Updated] (MRESOLVER-439) Collapse "jdk" transport modules

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-439:
--
Fix Version/s: 2.0.0-alpha-3

> Collapse "jdk" transport modules
> 
>
> Key: MRESOLVER-439
> URL: https://issues.apache.org/jira/browse/MRESOLVER-439
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-3
>
>
> The multi-release thing got out of control, is possible to be done in much 
> simpler way.



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

[jira] [Updated] (MRESOLVER-442) New JDK transport JAR mixes classes with different bytecode

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-442:
--
Fix Version/s: 2.0.0-alpha-3

> New JDK transport JAR mixes classes with different bytecode
> ---
>
> Key: MRESOLVER-442
> URL: https://issues.apache.org/jira/browse/MRESOLVER-442
> Project: Maven Resolver
>  Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-3
>
>
> And hence is unusable in projects that use Enforcer to enforce highest 
> allowed bytecode (like Maven is).



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

[jira] [Updated] (MRESOLVER-441) Undo FileUtils changes that altered non-Windows execution path

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-441:
--
Fix Version/s: 2.0.0-alpha-3

> Undo FileUtils changes that altered non-Windows execution path
> --
>
> Key: MRESOLVER-441
> URL: https://issues.apache.org/jira/browse/MRESOLVER-441
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.9.17
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.18, 2.0.0-alpha-3
>
>
> FileUtils was plagued by problems (sporadic AccessDeniedEx) when running on 
> Windows, but it worked without problems on other OSes. In MRESOLVER-372 
> released in 1.9.17 we fixed this by introducing an IF-ELSE construct that 
> does alternate "file copy" thing on Windows, but by mistake we altered the 
> ELSE branch that worked correctly in Resolver since version 1.9.0.
> This issue is really about reverting those change changes, and make same code 
> be used on non-Windows OSes as it was done since 1.9.0.



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

Re: [PR] Preparations for resolver alpha-3 [maven]

[via GitHub]

cstamas commented on PR #1328:
URL: https://github.com/apache/maven/pull/1328#issuecomment-1828696977

   Hm, did latest snapshot not deploy? Seems new `-apache` transport is not 
found...


-- 
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] Preparations for resolver alpha-3 [maven-integration-testing]

[via GitHub]

cstamas opened a new pull request, #322:
URL: https://github.com/apache/maven-integration-testing/pull/322

   Changes:
   * transport renames
   * some internals rename


-- 
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] Preparations for resolver alpha-3 [maven]

[via GitHub]

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

   Changes:
   * transport renames
   * some internals rename


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

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

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

Re: [I] Failed to install artifact xxx [maven-mvnd]

[via GitHub]

cstamas commented on issue #862:
URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1828674146

   Yes, maven 3.9.6 is to be released very very soon (tomorrow?)


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

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

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

Re: [I] Failed to install artifact xxx [maven-mvnd]

[via GitHub]

harryssuperman commented on issue #862:
URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1828671950

   After diving into the problem again, it is right now clear. 
   
   Problem has to be with 
[https://issues.apache.org/jira/browse/MRESOLVER-372](https://issues.apache.org/jira/browse/MRESOLVER-372
 ) i was coming back to version 3.9.3 and problem is not yet happening.
   
   Thanks @slawekjaranowski for the link and issue. Until next version with a 
fix, maybe 3.9.6?  I will let run for a hole week our CI Pipelines with the 
version 3.9.3 and i will update all of you next week.


-- 
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] Ensure we have a single JDK module [maven-resolver]

[via GitHub]

cstamas commented on PR #374:
URL: https://github.com/apache/maven-resolver/pull/374#issuecomment-1828652443

   I disagree with you, as MJAR in _this case_ is transparently handled by JDK 
classloader, as "Maven as resolver using code" in this case is completely 
oblivious (and should be oblivious) what is "changed" when running on different 
JDK versions. Moreover, the superiority of pattern that this PR replaced is 
visible in Central as well: 
   https://repo.maven.apache.org/maven2/org/apache/maven/resolver/
   
   Basically, each "constituent" JAR (along with proper bytecode) is deployed 
to Central, along with the `-jdk` MR one. This means, that consumer has a 
choice: to consume MR JAR or go directly for Java 11 without any fuss. IMHO, 
for libraries meant for downstream consumption, this is the cleanest and most 
"maven way" solution (and works in IDEs as well).


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

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

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

Re: [PR] [Refactor] Refactored implementation and design smells [maven-assembly-plugin]

[via GitHub]

slawekjaranowski commented on PR #161:
URL: 
https://github.com/apache/maven-assembly-plugin/pull/161#issuecomment-1828578614

   Good practice is execute locally  `mvn -P run-its clean verify` as we 
have described in PR template.
   
   Please also preserve in PR description at least line:
   
   > I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)


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

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

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

[jira] [Closed] (MASSEMBLY-1011) Bump maven-archiver from 3.6.0 to 3.6.1

[Slawomir Jaranowski (Jira)]

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

Slawomir Jaranowski closed MASSEMBLY-1011.
--
Resolution: Fixed

> Bump maven-archiver from 3.6.0 to 3.6.1
> ---
>
> Key: MASSEMBLY-1011
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1011
> Project: Maven Assembly Plugin
>  Issue Type: Dependency upgrade
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: next-release
>
>




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

[jira] [Commented] (MASSEMBLY-1011) Bump maven-archiver from 3.6.0 to 3.6.1

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790261#comment-17790261
 ] 

ASF GitHub Bot commented on MASSEMBLY-1011:
---

slawekjaranowski merged PR #169:
URL: https://github.com/apache/maven-assembly-plugin/pull/169




> Bump maven-archiver from 3.6.0 to 3.6.1
> ---
>
> Key: MASSEMBLY-1011
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1011
> Project: Maven Assembly Plugin
>  Issue Type: Dependency upgrade
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: next-release
>
>




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

Re: [PR] [MASSEMBLY-1011] Bump maven-archiver from 3.6.0 to 3.6.1 [maven-assembly-plugin]

[via GitHub]

slawekjaranowski merged PR #169:
URL: https://github.com/apache/maven-assembly-plugin/pull/169


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

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

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

[jira] [Commented] (MNG-7924) Better control over and better integration with Resolver

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MNG-7924:
-

cstamas merged PR #1299:
URL: https://github.com/apache/maven/pull/1299




> Better control over and better integration with Resolver
> 
>
> Key: MNG-7924
> URL: https://issues.apache.org/jira/browse/MNG-7924
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-alpha-9
>
>
> Integrate better and obtain better control over Resolver. These changes did 
> stem from "[JPMS module 
> experiment|https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support];
>  and are considered improvement but *does not implement any functionality* 
> related to JPMS module support.
> Changes:
> * Maven4 should stop "disconnected coexistence" of two type systems 
> (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
> * Maven4 Core should provide generic and extensible means to introduce new 
> artifact types (fully in extension, and extension should get extended data 
> via "roundtrip" in core/resolver)



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

Re: [PR] [MNG-7924] Better control over and better integration with Resolver [maven]

[via GitHub]

cstamas merged PR #1299:
URL: https://github.com/apache/maven/pull/1299


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

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/DOXIASITETOOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790215#comment-17790215
 ] 

Michael Osipov commented on DOXIASITETOOLS-320:
---

So I checked the code. A macro *cannot* instruct a target sink to emit 
additional anchors when the actual section title is hit. We can forget the 
macro idea. You should verify my findings though. I see only in 
{{org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(Writer,
 DocumentRenderingContext, SiteRenderingContext)}} for the moment. The parser 
needs a setter invoked, e.g., {{setSectionTitleAnchors(true)}}.

Regarding the answers:

* I agree that handling is complex, thus a warning should do.
* I think the reports can be ignored since they aren't subject to a parser, 
only sink and our solution should only fiddle with the parser.

> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIASITETOOLS-320
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-320
> Project: Maven Doxia Sitetools
>  Issue Type: Bug
>  Components: Site renderer
>Reporter: Slawomir Jaranowski
>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)

[jira] [Comment Edited] (DOXIASITETOOLS-320) Inconsistent anchors between toc macro and headers

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/DOXIASITETOOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790215#comment-17790215
 ] 

Michael Osipov edited comment on DOXIASITETOOLS-320 at 11/27/23 6:48 PM:
-

So I checked the code. A macro *cannot* instruct a target sink to emit 
additional anchors when the actual section title is hit. We can forget the 
macro idea. You should verify my findings though. I see only in 
{{org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(Writer,
 DocumentRenderingContext, SiteRenderingContext)}} for the moment. The parser 
needs a setter invoked, e.g., {{setSectionTitleAnchors(true)}}.

Regarding the answers:

* I agree that handling is complex, thus a warning should do.
* I think the reports can be ignored since they aren't subject to a parser, 
only sink and our solution should only fiddle with the parser.

Do you want to give it a try?


was (Author: michael-o):
So I checked the code. A macro *cannot* instruct a target sink to emit 
additional anchors when the actual section title is hit. We can forget the 
macro idea. You should verify my findings though. I see only in 
{{org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(Writer,
 DocumentRenderingContext, SiteRenderingContext)}} for the moment. The parser 
needs a setter invoked, e.g., {{setSectionTitleAnchors(true)}}.

Regarding the answers:

* I agree that handling is complex, thus a warning should do.
* I think the reports can be ignored since they aren't subject to a parser, 
only sink and our solution should only fiddle with the parser.

> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIASITETOOLS-320
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-320
> Project: Maven Doxia Sitetools
>  Issue Type: Bug
>  Components: Site renderer
>Reporter: Slawomir Jaranowski
>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] Ensure we have a single JDK module [maven-resolver]

[via GitHub]

rmannibucau commented on PR #374:
URL: https://github.com/apache/maven-resolver/pull/374#issuecomment-1828410981

   Strictly speaking:
   
   * IDE was unusable before (was lost between java version) so guess it is 
kind of a limitation of such setups
   * I did it when working on the PR so I assume you just didnt tune the 
compiler release version of the module?
   * enforcer has several pitfalls can be one but not sure why it would be 
worse than the mjar flavor, it stays java (actually what we do since > 10 years)
   * This is *not* broken, any fatjar is in this case and it is java friendly, 
actually MJAR is this kind of jar
   
   However mjar enforces:
   * more work on the jvm (classloading)
   * more work (or blocker) on any consumer that uses an IoC and scanner
   * more work (or blocker) on any consumer not using a flat classpath or 
classloader compatible with mjars (most of them actually, keep in mind EE does 
not know about modules and mjar yet, or several spring boot packaging flavors 
ignore it for ex)
   
   If the issue is just about mixing bytecode major version we can have jdk 
module (release=8) depending on jdk11 one and be it, would probably help with 
IDE issue too (for idea at least).
   
   That said I agree with your original analyzis that the IoC should skip the 
not loadable component (jdk8 there) and compiling everything with java 11 is 
the simplest, the 17/21 new API can be handled with reflection quite easily so 
sounds like the best compromise to me too.
   You mentionned sisu can break that but I guess we should just ensure it 
stays a feature either with a global or specific flag (ignorable classes or 
alike).


-- 
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=17790206#comment-17790206
 ] 

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



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

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



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

[jira] [Updated] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId, but different versions

[Michael Osipov (Jira)]

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

Michael Osipov updated MJAVADOC-682:

Fix Version/s: 3.6.3

> Reactor builds fail when multiple modules with same groupId:artifactId, but 
> different versions
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 
> 3.5.0, 3.6.0, 3.6.2
> Environment: Debian Linux versions 10.10 through 12.2
> OpenJDK 64-bit versions 11.0.11 through 17.0.9
> Maven versions 3.8.1 through 3.9.5
>Reporter: AO Industries, Inc.
>Assignee: Michael Osipov
>Priority: Major
>  Labels: jpms
> Fix For: 3.6.3
>
>
> In versions 3.1.0 through 3.6.2, when a reactor build has multiple projects 
> with the same groupId and artifactId, even when different versions, the 
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>  
> — Copy from demo project README.md —
> h2. To Reproduce:
>  # Clone this project: {{git clone 
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
>  # Change to project directory: {{cd 
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
>  # Perform build to see error in {{jar}} goal: {{mvn verify}}
>  # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
>  * Can build individual modules directly, such as {{(cd module-1 && mvn 
> verify)}}
>  * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
>  * Changing the groupId or artifactId in either module-1 or module-2 makes it 
> work.
>  * Changing module names, package names, or class names in modules has no 
> effect.
>  * We believe this to be distinct from [Issue 
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]



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

[jira] [Assigned] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId, but different versions

[Michael Osipov (Jira)]

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

Michael Osipov reassigned MJAVADOC-682:
---

Assignee: Michael Osipov

> Reactor builds fail when multiple modules with same groupId:artifactId, but 
> different versions
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 
> 3.5.0, 3.6.0, 3.6.2
> Environment: Debian Linux versions 10.10 through 12.2
> OpenJDK 64-bit versions 11.0.11 through 17.0.9
> Maven versions 3.8.1 through 3.9.5
>Reporter: AO Industries, Inc.
>Assignee: Michael Osipov
>Priority: Major
>  Labels: jpms
>
> In versions 3.1.0 through 3.6.2, when a reactor build has multiple projects 
> with the same groupId and artifactId, even when different versions, the 
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>  
> — Copy from demo project README.md —
> h2. To Reproduce:
>  # Clone this project: {{git clone 
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
>  # Change to project directory: {{cd 
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
>  # Perform build to see error in {{jar}} goal: {{mvn verify}}
>  # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
>  * Can build individual modules directly, such as {{(cd module-1 && mvn 
> verify)}}
>  * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
>  * Changing the groupId or artifactId in either module-1 or module-2 makes it 
> work.
>  * Changing module names, package names, or class names in modules has no 
> effect.
>  * We believe this to be distinct from [Issue 
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]



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

[jira] [Commented] (MRESOLVER-442) New JDK transport JAR mixes classes with different bytecode

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MRESOLVER-442:
--

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

   The current master builds JAR that it is not reusable in any project that 
uses enforcer (like Maven is).
   
   Make JAR "java 8" and let other (higher) byte classes get into their proper 
place.
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-442




> New JDK transport JAR mixes classes with different bytecode
> ---
>
> Key: MRESOLVER-442
> URL: https://issues.apache.org/jira/browse/MRESOLVER-442
> Project: Maven Resolver
>  Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> And hence is unusable in projects that use Enforcer to enforce highest 
> allowed bytecode (like Maven is).



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

[jira] [Commented] (MJAVADOC-764) javadoc:aggregate fails after Java 11 upgrade

[Sirisha Pratha (Jira)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790187#comment-17790187
 ] 

Sirisha Pratha commented on MJAVADOC-764:
-

This can be closed. 

> javadoc:aggregate fails after Java 11 upgrade 
> --
>
> Key: MJAVADOC-764
> URL: https://issues.apache.org/jira/browse/MJAVADOC-764
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Sirisha Pratha
>Priority: Critical
>  Labels: jpms
> Fix For: waiting-for-feedback
>
>
> We have a multi-module project that is failing for javadoc:aggregate goal 
> after upgrading to Java 11 for maven-javadoc-plugin versions 3.4.1 and 3.5.0.
> It worked fine without any issues for Java 1.8. 
> This is our maven-javadoc plugin configuration for Java 8 - 
> {color:#00875a}*SUCCESS*{color}
>  
> {noformat}
> 8
> 
>                 maven-javadoc-plugin
>                 
>                     ${maven.compiler.source} 
>                     Eclipse Collections - 
> ${project.version}
>                     Eclipse Collections - 
> ${project.version}
>                     public
>                     true
>                     
>                         https://junit.org/junit4/javadoc/latest
>                         
> https://docs.oracle.com/javase/8/docs/api/
>                     
>                     ${project.version}
>                     html,syntax,accessibility
>                     
>                         
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>                     
>                 
>                 
>                     
>                         aggregate
>                         false
>                         
>                             aggregate
>                         
>                     
>                 
>             
> {noformat}
> This is our maven-javadoc plugin configuration for Java 11 - (the only 
> difference is values in source and links tags) - 
> *{color:#ff}FAILS{color}* {color:#ff}(See error below){color}
>  
> {noformat}
> 11
> 
> maven-javadoc-plugin
> 
> ${maven.compiler.source}
> Eclipse Collections - 
> ${project.version}
> Eclipse Collections - 
> ${project.version}
> public
> true
> 
> https://junit.org/junit4/javadoc/latest
> 
> https://docs.oracle.com/en/java/javase/11/docs/api
> 
> ${project.version}
> html,syntax,accessibility
> 
> 
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
> 
> 
> 
> 
> aggregate
> false
> 
> aggregate
> 
> 
> 
> {noformat}
>  
> _javadoc:aggregate_ fails with the following error on our GitHub workflow 
> (nothing changed in the way we run this job - we have always used Java 17 to 
> run this) 
>  
> {noformat}
> Error: 6:236 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:aggregate (default-cli) 
> on project eclipse-collections-parent: An error has occurred in Javadoc 
> report generation: 
> 515Error: 6:236 [ERROR] Exit code: 2 - Loading source files for package 
> org.eclipse.collections.codegenerator.model...
> 516Error: 02:14:46:236 [ERROR] error: No source files for package 
> org.eclipse.collections.codegenerator.model
> 517Error: 02:14:46:237 [ERROR] 1 error
> 518Error: 6:237 [ERROR] 
> 519Error: 6:238 [ERROR] Command line was: 
> /opt/hostedtoolcache/Java_Zulu_jdk/17.0.7-7/x64/bin/javadoc @options @packages
> 520Error: 6:238 [ERROR] 
> 521Error: 6:238 [ERROR] Refer to the generated Javadoc files in 
> '/home/runner/work/eclipse-collections/eclipse-collections/target/site/apidocs/12.0.0-SNAPSHOT'
>  dir.
> 522Error: 6:239 [ERROR] 
> 523Error: 6:240 [ERROR] -> [Help 1]{noformat}
>  
>  
> Solutions we tried -
>  # Configuring sourcePath (see below) - in this case, *no Javadoc was 
> created* in target/site/apidocs. 
> {noformat}
> ${project.build.sourceDirectory}{noformat}
>  # Tried both plugin versions 3.4.1 and 3.5.0 - *fails* with both versions. 
>  # Tried to add source = 1.8 but maven.compiler.source = 11, which seems to 
> be the only combination that {*}works{*}. Like so -  
> {noformat}
> 11 
> 
> 

[jira] [Assigned] (MRESOLVER-442) New JDK transport JAR mixes classes with different bytecode

[Tamas Cservenak (Jira)]

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

Tamas Cservenak reassigned MRESOLVER-442:
-

Assignee: Tamas Cservenak

> New JDK transport JAR mixes classes with different bytecode
> ---
>
> Key: MRESOLVER-442
> URL: https://issues.apache.org/jira/browse/MRESOLVER-442
> Project: Maven Resolver
>  Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> And hence is unusable in projects that use Enforcer to enforce highest 
> allowed bytecode (like Maven is).



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

[jira] [Created] (MRESOLVER-442) New JDK transport JAR mixes classes with different bytecode

[Tamas Cservenak (Jira)]

Tamas Cservenak created MRESOLVER-442:
-

 Summary: New JDK transport JAR mixes classes with different 
bytecode
 Key: MRESOLVER-442
 URL: https://issues.apache.org/jira/browse/MRESOLVER-442
 Project: Maven Resolver
  Issue Type: Task
Reporter: Tamas Cservenak
 Fix For: 2.0.0


And hence is unusable in projects that use Enforcer to enforce highest allowed 
bytecode (like Maven is).



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

[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790182#comment-17790182
 ] 

Michael Osipov commented on SUREFIRE-2211:
--

This one is broken for me: 
[https://github.com/apache/maven-surefire/blob/aa864f4532282100667bf3d81dc7cbd460845408/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java#L228-L240]
 because this is pure form encoding, no URI encoding.

Spec: 
[https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html#class-path-attribute]

 

I wonder what would happen with entried like \{{böse.jar}} vs 
{{b{{{}%C3%B6{}}}.jar}}.

> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> We are using the configuration parameter additionalClasspathElements 
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
>  to provide a log4j2 xml configuration during tests. There is configured an 
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found 
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was 
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the 
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class 
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found 
> without issues. 



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

[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790178#comment-17790178
 ] 

Michael Osipov commented on SUREFIRE-2211:
--

Edit: Re-read. My understanding: {{Class-Path}} should only contain relative 
paths. Your absolute path is brittle and there for compat reasons. If present, 
it must use {{File}} only? Is that what Alan is trying to say? Regardless of 
this bug: Would it make sense for your to bundle it into a JAR to make it 
available as a dependency?

> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> We are using the configuration parameter additionalClasspathElements 
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
>  to provide a log4j2 xml configuration during tests. There is configured an 
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found 
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was 
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the 
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class 
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found 
> without issues. 



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

[jira] [Comment Edited] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790178#comment-17790178
 ] 

Michael Osipov edited comment on SUREFIRE-2211 at 11/27/23 4:55 PM:


Edit: Re-read. My understanding: {{Class-Path}} should only contain relative 
paths. Your absolute path is brittle and there for compat reasons. If present, 
it must use {{File}} only? Is that what Alan is trying to say? Regardless of 
this bug: Would it make sense for your to bundle it into a JAR to make it 
available as a dependency in the future?


was (Author: michael-o):
Edit: Re-read. My understanding: {{Class-Path}} should only contain relative 
paths. Your absolute path is brittle and there for compat reasons. If present, 
it must use {{File}} only? Is that what Alan is trying to say? Regardless of 
this bug: Would it make sense for your to bundle it into a JAR to make it 
available as a dependency?

> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> We are using the configuration parameter additionalClasspathElements 
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
>  to provide a log4j2 xml configuration during tests. There is configured an 
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found 
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was 
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the 
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class 
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found 
> without issues. 



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

[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790175#comment-17790175
 ] 

Michael Osipov commented on SUREFIRE-2211:
--

I do not fully understand Alan's answer and what type of solution Surefire 
should take. I will try to re-read his answer in the next couple of days.

> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> We are using the configuration parameter additionalClasspathElements 
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
>  to provide a log4j2 xml configuration during tests. There is configured an 
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found 
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was 
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the 
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class 
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found 
> without issues. 



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

[jira] [Commented] (MENFORCER-390) "requireFilesExist" no longer handles non-canonical paths

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790172#comment-17790172
 ] 

ASF GitHub Bot commented on MENFORCER-390:
--

roadSurfer commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1828211606

   That should be the whitepsace issues sorted. I also generated the site 
locally and it appeared OK to me.




> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>  Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks 
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
>  * absolute paths can involve symbolic links
>  * and they are allowed to have parts which are relative
>  ** {{/../}}
>  ** {{/./}}
> And when it fails to handle a path, it can report that a file does not exist, 
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
>  * requireFileExists
>  ** the provided path must resolve to a file (which may be a directory or 
> link)
>  * requireCanonicalFileExists
>  ** the provided path must exist as a canonical file
>  * requireCasesenstiveFileExists
>  ** the provided path must file a file
>  ** the file name must have the same case (upper//lower) as the
>  ** the parts of the path from the file up must have the same case until they 
> go through a symbolic link
> I have used  the "nio" package to handle some of stuff before.  I will add a 
> comment with some java code I would start with.  Since the outcome here is 
> very dependent on the use case you pick, the java will be "meta code" with 
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links 
> and such.
>  



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

Re: [PR] [MENFORCER-390] "requireFilesExist" no longer handles non-canonical paths [maven-enforcer]

[via GitHub]

roadSurfer commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1828211606

   That should be the whitepsace issues sorted. I also generated the site 
locally and it appeared OK to me.


-- 
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] Ensure we have a single JDK module [maven-resolver]

[via GitHub]

cstamas commented on PR #374:
URL: https://github.com/apache/maven-resolver/pull/374#issuecomment-1828151656

   It was a wrong decision of mine to merge the PR, this PR is merely a "smart 
hack" and as we know, every hack sooner or later will require more hacks down 
the road. Problems with this approach:
   * IDE is unusable
   * running UTs from IDE is imposible (due that above)
   * reusing the library is impossible in any downstream project that uses 
enforcer to enforce byte-code level
   * it produces "broken artifact", a JAR that mixes byte-code levels in non 
standard way (those classes are not in their "proper place" like 
META-INF/version but in root) -- this also have implications when enumerating 
classes on classpath with this jar on classpath...
   
   Am undoing this change.


-- 
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] [MENFORCER-390] "requireFilesExist" no longer handles non-canonical paths [maven-enforcer]

[via GitHub]

roadSurfer commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1828111369

   No, they are not intended. That will be my IDE doing its own thing, I'll
   use a different editor and update.
   
   On Mon, 27 Nov 2023 at 15:20, Torbjorn-Svensson ***@***.***>
   wrote:
   
   > Are all the white space changes in the .md files intended?
   > As far as I know, some of the trailing white spaces are needed in order to
   > not join the lines.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you authored the thread.Message ID:
   > ***@***.***>
   >
   


-- 
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] (MENFORCER-390) "requireFilesExist" no longer handles non-canonical paths

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790148#comment-17790148
 ] 

ASF GitHub Bot commented on MENFORCER-390:
--

roadSurfer commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1828111369

   No, they are not intended. That will be my IDE doing its own thing, I'll
   use a different editor and update.
   
   On Mon, 27 Nov 2023 at 15:20, Torbjorn-Svensson ***@***.***>
   wrote:
   
   > Are all the white space changes in the .md files intended?
   > As far as I know, some of the trailing white spaces are needed in order to
   > not join the lines.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   > You are receiving this because you authored the thread.Message ID:
   > ***@***.***>
   >
   




> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>  Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks 
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
>  * absolute paths can involve symbolic links
>  * and they are allowed to have parts which are relative
>  ** {{/../}}
>  ** {{/./}}
> And when it fails to handle a path, it can report that a file does not exist, 
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
>  * requireFileExists
>  ** the provided path must resolve to a file (which may be a directory or 
> link)
>  * requireCanonicalFileExists
>  ** the provided path must exist as a canonical file
>  * requireCasesenstiveFileExists
>  ** the provided path must file a file
>  ** the file name must have the same case (upper//lower) as the
>  ** the parts of the path from the file up must have the same case until they 
> go through a symbolic link
> I have used  the "nio" package to handle some of stuff before.  I will add a 
> comment with some java code I would start with.  Since the outcome here is 
> very dependent on the use case you pick, the java will be "meta code" with 
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links 
> and such.
>  



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

[jira] [Commented] (MENFORCER-390) "requireFilesExist" no longer handles non-canonical paths

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790126#comment-17790126
 ] 

ASF GitHub Bot commented on MENFORCER-390:
--

Torbjorn-Svensson commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1828041274

   Are all the white space changes in the .md files intended?
   As far as I know, some of the trailing white spaces are needed in order to 
not join the lines.




> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>  Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks 
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
>  * absolute paths can involve symbolic links
>  * and they are allowed to have parts which are relative
>  ** {{/../}}
>  ** {{/./}}
> And when it fails to handle a path, it can report that a file does not exist, 
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
>  * requireFileExists
>  ** the provided path must resolve to a file (which may be a directory or 
> link)
>  * requireCanonicalFileExists
>  ** the provided path must exist as a canonical file
>  * requireCasesenstiveFileExists
>  ** the provided path must file a file
>  ** the file name must have the same case (upper//lower) as the
>  ** the parts of the path from the file up must have the same case until they 
> go through a symbolic link
> I have used  the "nio" package to handle some of stuff before.  I will add a 
> comment with some java code I would start with.  Since the outcome here is 
> very dependent on the use case you pick, the java will be "meta code" with 
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links 
> and such.
>  



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

Re: [PR] [MENFORCER-390] "requireFilesExist" no longer handles non-canonical paths [maven-enforcer]

[via GitHub]

Torbjorn-Svensson commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1828041274

   Are all the white space changes in the .md files intended?
   As far as I know, some of the trailing white spaces are needed in order to 
not join the lines.


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

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

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

[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1

[Robert Seidel (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790111#comment-17790111
 ] 

Robert Seidel commented on SUREFIRE-2211:
-

Bug is now listed in JDK - https://bugs.openjdk.org/browse/JDK-8320760

> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> We are using the configuration parameter additionalClasspathElements 
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
>  to provide a log4j2 xml configuration during tests. There is configured an 
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found 
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was 
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the 
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class 
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found 
> without issues. 



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

[jira] [Closed] (MRESOLVER-321) Resolver while collecting may end up in busy loop without any possibility to be stopped

[Tamas Cservenak (Jira)]

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

Tamas Cservenak closed MRESOLVER-321.
-
Resolution: Fixed

> Resolver while collecting may end up in busy loop without any possibility to 
> be stopped
> ---
>
> Key: MRESOLVER-321
> URL: https://issues.apache.org/jira/browse/MRESOLVER-321
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As reported by users, under some conditions (MRESOLVER-316) resolver is able 
> to spin itself into busy loop, without possibility to stop it (ie. by 
> interrupting the thread of it).
> Example report: [https://github.com/apache/maven-resolver/pull/236]
> The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the 
> demo code and the diff for it).
> While the PR proposes a code change, that is not covering all, as in case of 
> MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
> visiting DependencyNodes).
> Solutiom: make collector but also visitor sense thread interruption.



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

[jira] [Commented] (MRESOLVER-321) Resolver while collecting may end up in busy loop without any possibility to be stopped

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MRESOLVER-321:
--

cstamas merged PR #380:
URL: https://github.com/apache/maven-resolver/pull/380




> Resolver while collecting may end up in busy loop without any possibility to 
> be stopped
> ---
>
> Key: MRESOLVER-321
> URL: https://issues.apache.org/jira/browse/MRESOLVER-321
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As reported by users, under some conditions (MRESOLVER-316) resolver is able 
> to spin itself into busy loop, without possibility to stop it (ie. by 
> interrupting the thread of it).
> Example report: [https://github.com/apache/maven-resolver/pull/236]
> The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the 
> demo code and the diff for it).
> While the PR proposes a code change, that is not covering all, as in case of 
> MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
> visiting DependencyNodes).
> Solutiom: make collector but also visitor sense thread interruption.



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

Re: [PR] [MRESOLVER-321] Make collection and visiting interruptable [maven-resolver]

[via GitHub]

cstamas merged PR #380:
URL: https://github.com/apache/maven-resolver/pull/380


-- 
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] (MJAVADOC-722) Allow Logging Javadoc Warnings and Errors to File

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790092#comment-17790092
 ] 

ASF GitHub Bot commented on MJAVADOC-722:
-

alzimmermsft commented on PR #159:
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/159#issuecomment-1827905944

   > @alzimmermsft Can you rebase, I will take another look at it. I have now a 
better understanding of this plugin. Ideally, can you also create an IT where 
such an output is depicted as well?
   
   Gladly, I will rebase this change soon and will add an integration test when 
I do that.
   
   Since it's been a while, do you still want `@errors` replaced with using 
`outputFile` to completely redirect error output? Similar to what is seen with 
plugins like Maven Dependency where `outputFile` completely redirects the 
output.




> Allow Logging Javadoc Warnings and Errors to File
> -
>
> Key: MJAVADOC-722
> URL: https://issues.apache.org/jira/browse/MJAVADOC-722
> Project: Maven Javadoc Plugin
>  Issue Type: New Feature
>  Components: javadoc
>Reporter: Alan Zimmer
>Priority: Trivial
>
> Allow for Javadoc generation, either implicitly or through a new 
> configuration, to generate a file containing the warnings and errors that 
> were found during Javadoc generation. Possibly following a similar pattern to 
> the argfile  and options that are generated containing parameters passed to 
> Javadoc create an errors files that will be placed in the Javadoc output 
> folder that is ignored during Javadoc JAR creation.
>  
> This change would allow for CI systems to run Javadoc builds in parallel 
> while still easily capturing any errors without the need for complex logging 
> systems and would strongly ensure that there is a unique error report for 
> each project.



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

Re: [PR] [MJAVADOC-722] Log javadoc warnings and errors to file [maven-javadoc-plugin]

[via GitHub]

alzimmermsft commented on PR #159:
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/159#issuecomment-1827905944

   > @alzimmermsft Can you rebase, I will take another look at it. I have now a 
better understanding of this plugin. Ideally, can you also create an IT where 
such an output is depicted as well?
   
   Gladly, I will rebase this change soon and will add an integration test when 
I do that.
   
   Since it's been a while, do you still want `@errors` replaced with using 
`outputFile` to completely redirect error output? Similar to what is seen with 
plugins like Maven Dependency where `outputFile` completely redirects the 
output.


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

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

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

[PR] Bump org.jsoup:jsoup from 1.16.2 to 1.17.1 [maven-plugin-tools]

[via GitHub]

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

   Bumps [org.jsoup:jsoup](https://github.com/jhy/jsoup) from 1.16.2 to 1.17.1.
   
   Release notes
   Sourced from https://github.com/jhy/jsoup/releases;>org.jsoup:jsoup's 
releases.
   
   jsoup 1.17.1
   
   
   
   
   ... (truncated)
   
   
   Changelog
   Sourced from https://github.com/jhy/jsoup/blob/master/CHANGES;>org.jsoup:jsoup's 
changelog.
   
   jsoup changelog
   Release 1.17.1 [27-Nov-2023]
   
   
   Improvement: in Jsoup.connect(), added support for request-level 
authentication, supporting authentication to
   proxies and to servers.
   https://redirect.github.com/jhy/jsoup/pull/2046;>jhy/jsoup#2046
   
   
   Improvement: in the Elements list, added direct support for 
#set(index, element), #remove(index),
   #remove(object), #clear(), 
#removeAll(collection), #retainAll(collection), 
#removeIf(filter),
   #replaceAll(operator). These methods update the original DOM, 
as well as the Elements list.
   https://redirect.github.com/jhy/jsoup/pull/2017;>jhy/jsoup#2017
   
   
   Improvement: added the NodeIterator class, to efficiently traverse a node 
tree using the Iterator interface. And
   added Stream Element#stream() and Node#nodeStream() methods, to enable 
fluent composable stream pipelines of node
   traversals.
   https://redirect.github.com/jhy/jsoup/pull/2051;>jhy/jsoup#2051
   
   
   Improvement: when changing the OutputSettings syntax to XML, the xhtml 
EscapeMode is automatically set by default.
   
   
   Improvement: added the :is(selector list) pseudo-selector, 
which finds elements that match any of the selectors in
   the selector list. Useful for making large ORed selectors more readable.
   
   
   Improvement: repackaged the library with native (vs automatic) JPMS 
module support.
   https://redirect.github.com/jhy/jsoup/pull/2025;>jhy/jsoup#2025
   
   
   Improvement: better fidelity of source positions when tracking is 
enabled. And implicitly created or closed elements
   are tracked and detectable via Range.isImplicit().
   https://redirect.github.com/jhy/jsoup/pull/2056;>jhy/jsoup#2056
   
   
   Improvement: when source tracking is enabled, the source position for 
attribute names and values is now available.
   Attribute#sourceRange() provides the ranges.
   https://redirect.github.com/jhy/jsoup/pull/2057;>jhy/jsoup#2057
   
   
   Improvement: when running concurrently under Java 21+ Virtual Threads, 
virtual threads could be pinned to their
   carrier platform thread when parsing an input stream. To improve 
performance, particularly when parsing fetched
   URLs, the internal ConstrainableInputStream has been replaced by 
ControllableInputStream, which avoids the locking
   which caused that pinning.
   https://redirect.github.com/jhy/jsoup/issues/2054;>jhy/jsoup#2054
   
   
   Improvement: in Jsoup.Connect, allow any XML mimetype as a supported 
mimetype. Was previously limited to
   {application|text}/xml. This enables for e.g. fetching SVGs 
with a image/svg+xml mimetype, without having to
   disable mimetype validation.
   https://redirect.github.com/jhy/jsoup/issues/2059;>jhy/jsoup#2059
   
   
   Bugfix: when outputting with XML syntax, HTML elements that were parsed 
as data nodes ( and ) should
   be emitted as CDATA nodes, so that they can be parsed correctly by an XML 
parser.
   https://redirect.github.com/jhy/jsoup/pull/1720;>jhy/jsoup#1720
   
   
   Bugfix: the Immediate Parent selector  could match 
elements above the root context element, causing incorrect
   elements to be returned when used on elements other than the root 
document.
   
   
   
   
   ... (truncated)
   
   
   Commits
   
   https://github.com/jhy/jsoup/commit/8eecef379d5c5af27a9a438fdfce82460e44f08b;>8eecef3
 [maven-release-plugin] prepare release jsoup-1.17.1
   https://github.com/jhy/jsoup/commit/a6c195080466bb3cb7c5a4527622b8f49c7639ad;>a6c1950
 In javadoc, emit links to source
   https://github.com/jhy/jsoup/commit/00f85a826668e5dc1e7b180bba52f35ccb9dbaaf;>00f85a8
 Revised Connection.data javadoc
   https://github.com/jhy/jsoup/commit/f49dd2c7134b23a6c8f72030ef581bb1098c8576;>f49dd2c
 PR url
   https://github.com/jhy/jsoup/commit/4b91adf9a4afb4eaf0e815c48b5d2cfdcb639f66;>4b91adf
 Simpler empty test
   https://github.com/jhy/jsoup/commit/73d450657932370e516f205537b395d1d055d043;>73d4506
 Refactored UserData to be tucked into a hash (https://redirect.github.com/jhy/jsoup/issues/2060;>#2060)
   https://github.com/jhy/jsoup/commit/58521a45067f5c4fa558cb090480fa4b2e407056;>58521a4
 Allow any XML mimetype in Connection
   https://github.com/jhy/jsoup/commit/bc798109ea212dc6117a31c114a0b3641d2658a5;>bc79810
 Specify overrides
   https://github.com/jhy/jsoup/commit/0a737674a52c5cda41aff7a58154d4073fcd3d6c;>0a73767
 Re-specify IteratorAttribute type
   https://github.com/jhy/jsoup/commit/4669e14039a976644e8fcd53bed422b11d32dfeb;>4669e14
 Make Attributes iterator 

[jira] [Commented] (SUREFIRE-2217) Surefire wrongly reports number of Junit tests run for test classes with common base class

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790078#comment-17790078
 ] 

Michael Osipov commented on SUREFIRE-2217:
--

In serial, it does work?

> Surefire wrongly reports number of Junit tests run for test classes with 
> common base class
> --
>
> Key: SUREFIRE-2217
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2217
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Lukasz Osipiuk
>Priority: Minor
>
> Surefire wrongly reports number of Junit tests run for test classes with 
> common base class when subclasses are run concurrently.
> It looks like when first test class completes surefire reports the number of 
> tests which have been run which is sum of tests run so far from both 
> subclasses.
>  
> Observed in trinodb/trino. See this issue: 
> [https://github.com/trinodb/trino/issues/19908]
>  
> cc: [~findepi] [~martint] 



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

[jira] [Commented] (SUREFIRE-2217) Surefire wrongly reports number of Junit tests run for test classes with common base class

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790077#comment-17790077
 ] 

Michael Osipov commented on SUREFIRE-2217:
--

 wonder whether this could a race condition while updating counters...

> Surefire wrongly reports number of Junit tests run for test classes with 
> common base class
> --
>
> Key: SUREFIRE-2217
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2217
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Lukasz Osipiuk
>Priority: Minor
>
> Surefire wrongly reports number of Junit tests run for test classes with 
> common base class when subclasses are run concurrently.
> It looks like when first test class completes surefire reports the number of 
> tests which have been run which is sum of tests run so far from both 
> subclasses.
>  
> Observed in trinodb/trino. See this issue: 
> [https://github.com/trinodb/trino/issues/19908]
>  
> cc: [~findepi] [~martint] 



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

[jira] [Commented] (MRESOLVER-321) Resolver while collecting may end up in busy loop without any possibility to be stopped

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MRESOLVER-321:
--

cstamas commented on code in PR #380:
URL: https://github.com/apache/maven-resolver/pull/380#discussion_r1406111216


##
maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java:
##
@@ -286,6 +286,9 @@ public void setData(Object key, Object value) {
 }
 
 public boolean accept(DependencyVisitor visitor) {
+if (Thread.currentThread().isInterrupted()) {
+throw new RuntimeException("Thread interrupted");

Review Comment:
   fixed





> Resolver while collecting may end up in busy loop without any possibility to 
> be stopped
> ---
>
> Key: MRESOLVER-321
> URL: https://issues.apache.org/jira/browse/MRESOLVER-321
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As reported by users, under some conditions (MRESOLVER-316) resolver is able 
> to spin itself into busy loop, without possibility to stop it (ie. by 
> interrupting the thread of it).
> Example report: [https://github.com/apache/maven-resolver/pull/236]
> The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the 
> demo code and the diff for it).
> While the PR proposes a code change, that is not covering all, as in case of 
> MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
> visiting DependencyNodes).
> Solutiom: make collector but also visitor sense thread interruption.



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

Re: [PR] [MRESOLVER-321] Make collection and visiting interruptable [maven-resolver]

[via GitHub]

cstamas commented on code in PR #380:
URL: https://github.com/apache/maven-resolver/pull/380#discussion_r1406111216


##
maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java:
##
@@ -286,6 +286,9 @@ public void setData(Object key, Object value) {
 }
 
 public boolean accept(DependencyVisitor visitor) {
+if (Thread.currentThread().isInterrupted()) {
+throw new RuntimeException("Thread interrupted");

Review Comment:
   fixed



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

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

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

[PR] Bump org.jsoup:jsoup from 1.15.3 to 1.17.1 [maven-dist-tool]

[via GitHub]

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

   Bumps [org.jsoup:jsoup](https://github.com/jhy/jsoup) from 1.15.3 to 1.17.1.
   
   Release notes
   Sourced from https://github.com/jhy/jsoup/releases;>org.jsoup:jsoup's 
releases.
   
   jsoup 1.17.1
   
   
   
   
   ... (truncated)
   
   
   Changelog
   Sourced from https://github.com/jhy/jsoup/blob/master/CHANGES;>org.jsoup:jsoup's 
changelog.
   
   jsoup changelog
   Release 1.17.1 [27-Nov-2023]
   
   
   Improvement: in Jsoup.connect(), added support for request-level 
authentication, supporting authentication to
   proxies and to servers.
   https://redirect.github.com/jhy/jsoup/pull/2046;>jhy/jsoup#2046
   
   
   Improvement: in the Elements list, added direct support for 
#set(index, element), #remove(index),
   #remove(object), #clear(), 
#removeAll(collection), #retainAll(collection), 
#removeIf(filter),
   #replaceAll(operator). These methods update the original DOM, 
as well as the Elements list.
   https://redirect.github.com/jhy/jsoup/pull/2017;>jhy/jsoup#2017
   
   
   Improvement: added the NodeIterator class, to efficiently traverse a node 
tree using the Iterator interface. And
   added Stream Element#stream() and Node#nodeStream() methods, to enable 
fluent composable stream pipelines of node
   traversals.
   https://redirect.github.com/jhy/jsoup/pull/2051;>jhy/jsoup#2051
   
   
   Improvement: when changing the OutputSettings syntax to XML, the xhtml 
EscapeMode is automatically set by default.
   
   
   Improvement: added the :is(selector list) pseudo-selector, 
which finds elements that match any of the selectors in
   the selector list. Useful for making large ORed selectors more readable.
   
   
   Improvement: repackaged the library with native (vs automatic) JPMS 
module support.
   https://redirect.github.com/jhy/jsoup/pull/2025;>jhy/jsoup#2025
   
   
   Improvement: better fidelity of source positions when tracking is 
enabled. And implicitly created or closed elements
   are tracked and detectable via Range.isImplicit().
   https://redirect.github.com/jhy/jsoup/pull/2056;>jhy/jsoup#2056
   
   
   Improvement: when source tracking is enabled, the source position for 
attribute names and values is now available.
   Attribute#sourceRange() provides the ranges.
   https://redirect.github.com/jhy/jsoup/pull/2057;>jhy/jsoup#2057
   
   
   Improvement: when running concurrently under Java 21+ Virtual Threads, 
virtual threads could be pinned to their
   carrier platform thread when parsing an input stream. To improve 
performance, particularly when parsing fetched
   URLs, the internal ConstrainableInputStream has been replaced by 
ControllableInputStream, which avoids the locking
   which caused that pinning.
   https://redirect.github.com/jhy/jsoup/issues/2054;>jhy/jsoup#2054
   
   
   Improvement: in Jsoup.Connect, allow any XML mimetype as a supported 
mimetype. Was previously limited to
   {application|text}/xml. This enables for e.g. fetching SVGs 
with a image/svg+xml mimetype, without having to
   disable mimetype validation.
   https://redirect.github.com/jhy/jsoup/issues/2059;>jhy/jsoup#2059
   
   
   Bugfix: when outputting with XML syntax, HTML elements that were parsed 
as data nodes ( and ) should
   be emitted as CDATA nodes, so that they can be parsed correctly by an XML 
parser.
   https://redirect.github.com/jhy/jsoup/pull/1720;>jhy/jsoup#1720
   
   
   Bugfix: the Immediate Parent selector  could match 
elements above the root context element, causing incorrect
   elements to be returned when used on elements other than the root 
document.
   
   
   
   
   ... (truncated)
   
   
   Commits
   
   https://github.com/jhy/jsoup/commit/8eecef379d5c5af27a9a438fdfce82460e44f08b;>8eecef3
 [maven-release-plugin] prepare release jsoup-1.17.1
   https://github.com/jhy/jsoup/commit/a6c195080466bb3cb7c5a4527622b8f49c7639ad;>a6c1950
 In javadoc, emit links to source
   https://github.com/jhy/jsoup/commit/00f85a826668e5dc1e7b180bba52f35ccb9dbaaf;>00f85a8
 Revised Connection.data javadoc
   https://github.com/jhy/jsoup/commit/f49dd2c7134b23a6c8f72030ef581bb1098c8576;>f49dd2c
 PR url
   https://github.com/jhy/jsoup/commit/4b91adf9a4afb4eaf0e815c48b5d2cfdcb639f66;>4b91adf
 Simpler empty test
   https://github.com/jhy/jsoup/commit/73d450657932370e516f205537b395d1d055d043;>73d4506
 Refactored UserData to be tucked into a hash (https://redirect.github.com/jhy/jsoup/issues/2060;>#2060)
   https://github.com/jhy/jsoup/commit/58521a45067f5c4fa558cb090480fa4b2e407056;>58521a4
 Allow any XML mimetype in Connection
   https://github.com/jhy/jsoup/commit/bc798109ea212dc6117a31c114a0b3641d2658a5;>bc79810
 Specify overrides
   https://github.com/jhy/jsoup/commit/0a737674a52c5cda41aff7a58154d4073fcd3d6c;>0a73767
 Re-specify IteratorAttribute type
   https://github.com/jhy/jsoup/commit/4669e14039a976644e8fcd53bed422b11d32dfeb;>4669e14
 Make Attributes iterator throw 

Re: [PR] Bump org.jsoup:jsoup from 1.15.3 to 1.16.2 [maven-dist-tool]

[via GitHub]

dependabot[bot] closed pull request #38: Bump org.jsoup:jsoup from 1.15.3 to 
1.16.2
URL: https://github.com/apache/maven-dist-tool/pull/38


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

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

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

Re: [PR] Bump org.jsoup:jsoup from 1.15.3 to 1.16.2 [maven-dist-tool]

[via GitHub]

dependabot[bot] commented on PR #38:
URL: https://github.com/apache/maven-dist-tool/pull/38#issuecomment-1827711142

   Superseded by #39.


-- 
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-321) Resolver while collecting may end up in busy loop without any possibility to be stopped

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MRESOLVER-321:
--

gnodet commented on code in PR #380:
URL: https://github.com/apache/maven-resolver/pull/380#discussion_r1406063530


##
maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java:
##
@@ -286,6 +286,9 @@ public void setData(Object key, Object value) {
 }
 
 public boolean accept(DependencyVisitor visitor) {
+if (Thread.currentThread().isInterrupted()) {
+throw new RuntimeException("Thread interrupted");

Review Comment:
   We need a way for the caller to know that the exception was caused by the 
thread being interrupted.
   At least `new RuntimeException(new InterruptedException("Thread 
interrupted"))` ?





> Resolver while collecting may end up in busy loop without any possibility to 
> be stopped
> ---
>
> Key: MRESOLVER-321
> URL: https://issues.apache.org/jira/browse/MRESOLVER-321
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As reported by users, under some conditions (MRESOLVER-316) resolver is able 
> to spin itself into busy loop, without possibility to stop it (ie. by 
> interrupting the thread of it).
> Example report: [https://github.com/apache/maven-resolver/pull/236]
> The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the 
> demo code and the diff for it).
> While the PR proposes a code change, that is not covering all, as in case of 
> MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
> visiting DependencyNodes).
> Solutiom: make collector but also visitor sense thread interruption.



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

Re: [PR] [MRESOLVER-321] Make collection and visiting interruptable [maven-resolver]

[via GitHub]

gnodet commented on code in PR #380:
URL: https://github.com/apache/maven-resolver/pull/380#discussion_r1406063530


##
maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java:
##
@@ -286,6 +286,9 @@ public void setData(Object key, Object value) {
 }
 
 public boolean accept(DependencyVisitor visitor) {
+if (Thread.currentThread().isInterrupted()) {
+throw new RuntimeException("Thread interrupted");

Review Comment:
   We need a way for the caller to know that the exception was caused by the 
thread being interrupted.
   At least `new RuntimeException(new InterruptedException("Thread 
interrupted"))` ?



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

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

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

[jira] [Assigned] (MRESOLVER-321) Resolver while collecting may end up in busy loop without any possibility to be stopped

[Tamas Cservenak (Jira)]

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

Tamas Cservenak reassigned MRESOLVER-321:
-

Assignee: Tamas Cservenak

> Resolver while collecting may end up in busy loop without any possibility to 
> be stopped
> ---
>
> Key: MRESOLVER-321
> URL: https://issues.apache.org/jira/browse/MRESOLVER-321
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As reported by users, under some conditions (MRESOLVER-316) resolver is able 
> to spin itself into busy loop, without possibility to stop it (ie. by 
> interrupting the thread of it).
> Example report: [https://github.com/apache/maven-resolver/pull/236]
> The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the 
> demo code and the diff for it).
> While the PR proposes a code change, that is not covering all, as in case of 
> MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
> visiting DependencyNodes).
> Solutiom: make collector but also visitor sense thread interruption.



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

[jira] [Updated] (MRESOLVER-321) Resolver while collecting may end up in busy loop without any possibility to be stopped

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MRESOLVER-321:
--
Description: 
As reported by users, under some conditions (MRESOLVER-316) resolver is able to 
spin itself into busy loop, without possibility to stop it (ie. by interrupting 
the thread of it).

Example report: [https://github.com/apache/maven-resolver/pull/236]

The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the demo 
code and the diff for it).

While the PR proposes a code change, that is not covering all, as in case of 
MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
visiting DependencyNodes).

Solutiom: make collector but also visitor sense thread interruption.

  was:
As reported by users, under some conditions (MRESOLVER-316) resolver is able to 
spin itself into busy loop, without possibility to stop it (ie. by interrupting 
the thread of it).

Example report: [https://github.com/apache/maven-resolver/pull/236]

The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the demo 
code and the diff for it).

While the PR proposes a code change, that is not covering all, as in case of 
MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
visiting DependencyNodes).


> Resolver while collecting may end up in busy loop without any possibility to 
> be stopped
> ---
>
> Key: MRESOLVER-321
> URL: https://issues.apache.org/jira/browse/MRESOLVER-321
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As reported by users, under some conditions (MRESOLVER-316) resolver is able 
> to spin itself into busy loop, without possibility to stop it (ie. by 
> interrupting the thread of it).
> Example report: [https://github.com/apache/maven-resolver/pull/236]
> The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the 
> demo code and the diff for it).
> While the PR proposes a code change, that is not covering all, as in case of 
> MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
> visiting DependencyNodes).
> Solutiom: make collector but also visitor sense thread interruption.



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

Re: [PR] handle thread interrupts on transitive dependencies parsing (infinite loop) [maven-resolver]

[via GitHub]

cstamas commented on PR #236:
URL: https://github.com/apache/maven-resolver/pull/236#issuecomment-1827667154

   Superseded by https://github.com/apache/maven-resolver/pull/380
   
   Now both collectors are "interrupt aware" and will handle same way 
interruption (see UT).


-- 
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] [MRESOLVER-321] Make collection interruptable [maven-resolver]

[via GitHub]

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

   Currently the two collection are not interruptable, does not sense 
interruption directly, only by some side-effect like IO. Moreover, the BF new 
collector may enter a "busy loop" as we seen, true, it was
   due bug, but nothing prevents us to have more bugs.
   
   Make main loop in both collector detect thread interruption and use global 
(per-collection) Args to carry state of the, interruption effectively the whole 
ST or MT
   collection.
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-321


-- 
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-321) Resolver while collecting may end up in busy loop without any possibility to be stopped

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MRESOLVER-321:
--

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

   Currently the two collection are not interruptable, does not sense 
interruption directly, only by some side-effect like IO. Moreover, the BF new 
collector may enter a "busy loop" as we seen, true, it was
   due bug, but nothing prevents us to have more bugs.
   
   Make main loop in both collector detect thread interruption and use global 
(per-collection) Args to carry state of the, interruption effectively the whole 
ST or MT
   collection.
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-321




> Resolver while collecting may end up in busy loop without any possibility to 
> be stopped
> ---
>
> Key: MRESOLVER-321
> URL: https://issues.apache.org/jira/browse/MRESOLVER-321
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As reported by users, under some conditions (MRESOLVER-316) resolver is able 
> to spin itself into busy loop, without possibility to stop it (ie. by 
> interrupting the thread of it).
> Example report: [https://github.com/apache/maven-resolver/pull/236]
> The reproducer (until MRESOLVER-316 is fixed) is present in PR above (the 
> demo code and the diff for it).
> While the PR proposes a code change, that is not covering all, as in case of 
> MRESOLVER-316 bug, the endless loop happens in visitor bit (DependencyVisitor 
> visiting DependencyNodes).



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

[jira] [Created] (SUREFIRE-2217) Surefire wrongly reports number of Junit tests run for test classes with common base class

[Lukasz Osipiuk (Jira)]

Lukasz Osipiuk created SUREFIRE-2217:


 Summary: Surefire wrongly reports number of Junit tests run for 
test classes with common base class
 Key: SUREFIRE-2217
 URL: https://issues.apache.org/jira/browse/SUREFIRE-2217
 Project: Maven Surefire
  Issue Type: Bug
Reporter: Lukasz Osipiuk


Surefire wrongly reports number of Junit tests run for test classes with common 
base class when subclasses are run concurrently.

It looks like when first test class completes surefire reports the number of 
tests which have been run which is sum of tests run so far from both subclasses.

 

Observed in trinodb/trino. See this issue: 
[https://github.com/trinodb/trino/issues/19908]

 

cc: [~findepi] [~martint] 



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

[jira] [Updated] (SUREFIRE-2217) Surefire wrongly reports number of Junit tests run for test classes with common base class

[Lukasz Osipiuk (Jira)]

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

Lukasz Osipiuk updated SUREFIRE-2217:
-
Priority: Minor  (was: Major)

> Surefire wrongly reports number of Junit tests run for test classes with 
> common base class
> --
>
> Key: SUREFIRE-2217
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2217
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Lukasz Osipiuk
>Priority: Minor
>
> Surefire wrongly reports number of Junit tests run for test classes with 
> common base class when subclasses are run concurrently.
> It looks like when first test class completes surefire reports the number of 
> tests which have been run which is sum of tests run so far from both 
> subclasses.
>  
> Observed in trinodb/trino. See this issue: 
> [https://github.com/trinodb/trino/issues/19908]
>  
> cc: [~findepi] [~martint] 



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

[jira] [Commented] (MRESOLVER-429) Enhance JDK transport error messaging

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MRESOLVER-429:
--

cstamas merged PR #379:
URL: https://github.com/apache/maven-resolver/pull/379




> Enhance JDK transport error messaging
> -
>
> Key: MRESOLVER-429
> URL: https://issues.apache.org/jira/browse/MRESOLVER-429
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Currently we rely fully on JDK HttpClient error message for example in case 
> of connection refused: message is "ConnectException", just that. We could 
> improve this, make it more humane.



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

[jira] [Closed] (MRESOLVER-429) Enhance JDK transport error messaging

[Tamas Cservenak (Jira)]

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

Tamas Cservenak closed MRESOLVER-429.
-
Resolution: Fixed

> Enhance JDK transport error messaging
> -
>
> Key: MRESOLVER-429
> URL: https://issues.apache.org/jira/browse/MRESOLVER-429
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Currently we rely fully on JDK HttpClient error message for example in case 
> of connection refused: message is "ConnectException", just that. We could 
> improve this, make it more humane.



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

Re: [PR] [MRESOLVER-429] Emit more informative message on connection refused [maven-resolver]

[via GitHub]

cstamas merged PR #379:
URL: https://github.com/apache/maven-resolver/pull/379


-- 
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] (MENFORCER-390) "requireFilesExist" no longer handles non-canonical paths

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790025#comment-17790025
 ] 

ASF GitHub Bot commented on MENFORCER-390:
--

roadSurfer commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1827585294

   I have added some words to the affected documentation on case-sensitivity, 
as well as some explic testing of symbolic links.




> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>  Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks 
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
>  * absolute paths can involve symbolic links
>  * and they are allowed to have parts which are relative
>  ** {{/../}}
>  ** {{/./}}
> And when it fails to handle a path, it can report that a file does not exist, 
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
>  * requireFileExists
>  ** the provided path must resolve to a file (which may be a directory or 
> link)
>  * requireCanonicalFileExists
>  ** the provided path must exist as a canonical file
>  * requireCasesenstiveFileExists
>  ** the provided path must file a file
>  ** the file name must have the same case (upper//lower) as the
>  ** the parts of the path from the file up must have the same case until they 
> go through a symbolic link
> I have used  the "nio" package to handle some of stuff before.  I will add a 
> comment with some java code I would start with.  Since the outcome here is 
> very dependent on the use case you pick, the java will be "meta code" with 
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links 
> and such.
>  



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

Re: [PR] [MENFORCER-390] "requireFilesExist" no longer handles non-canonical paths [maven-enforcer]

[via GitHub]

roadSurfer commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1827585294

   I have added some words to the affected documentation on case-sensitivity, 
as well as some explic testing of symbolic links.


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

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

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

[jira] [Updated] (MNG-7946) Undo JDK transport related changes once on alpha-3

[Tamas Cservenak (Jira)]

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

Tamas Cservenak updated MNG-7946:
-
Fix Version/s: 4.0.0

> Undo JDK transport related changes once on alpha-3
> --
>
> Key: MNG-7946
> URL: https://issues.apache.org/jira/browse/MNG-7946
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> When we switched to Resolver 2 alpha, the JDK transport caused changes in 
> some ITs due changed error message. MRESOLVER-429 fixes that, will be in 
> alpha-3.
> Once we are on alpha-3, this IT change should be undone:
> https://github.com/apache/maven-integration-testing/commit/53d7ae5492ef58cf5a43c3cfa421e6457b5f6f9d



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

[jira] [Created] (MNG-7946) Undo JDK transport related changes once on alpha-3

[Tamas Cservenak (Jira)]

Tamas Cservenak created MNG-7946:


 Summary: Undo JDK transport related changes once on alpha-3
 Key: MNG-7946
 URL: https://issues.apache.org/jira/browse/MNG-7946
 Project: Maven
  Issue Type: Task
  Components: Artifacts and Repositories
Reporter: Tamas Cservenak
 Fix For: 4.0.0-alpha-9


When we switched to Resolver 2 alpha, the JDK transport caused changes in some 
ITs due changed error message. MRESOLVER-429 fixes that, will be in alpha-3.

Once we are on alpha-3, this IT change should be undone:

https://github.com/apache/maven-integration-testing/commit/53d7ae5492ef58cf5a43c3cfa421e6457b5f6f9d



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

[jira] [Commented] (MRESOLVER-429) Enhance JDK transport error messaging

[Tamas Cservenak (Jira)]

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

Tamas Cservenak commented on MRESOLVER-429:
---

Ideally the IT changes should be undone once this merged.

> Enhance JDK transport error messaging
> -
>
> Key: MRESOLVER-429
> URL: https://issues.apache.org/jira/browse/MRESOLVER-429
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Currently we rely fully on JDK HttpClient error message for example in case 
> of connection refused: message is "ConnectException", just that. We could 
> improve this, make it more humane.



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

[jira] [Assigned] (MRESOLVER-429) Enhance JDK transport error messaging

[Tamas Cservenak (Jira)]

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

Tamas Cservenak reassigned MRESOLVER-429:
-

Assignee: Tamas Cservenak

> Enhance JDK transport error messaging
> -
>
> Key: MRESOLVER-429
> URL: https://issues.apache.org/jira/browse/MRESOLVER-429
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Currently we rely fully on JDK HttpClient error message for example in case 
> of connection refused: message is "ConnectException", just that. We could 
> improve this, make it more humane.



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

[jira] [Commented] (MRESOLVER-429) Enhance JDK transport error messaging

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot commented on MRESOLVER-429:
--

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

   By default HTTP Client is quite muted, message is "ConnectException".
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-429




> Enhance JDK transport error messaging
> -
>
> Key: MRESOLVER-429
> URL: https://issues.apache.org/jira/browse/MRESOLVER-429
> Project: Maven Resolver
>  Issue Type: Task
>  Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Currently we rely fully on JDK HttpClient error message for example in case 
> of connection refused: message is "ConnectException", just that. We could 
> improve this, make it more humane.



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

[PR] [MRESOLVER-429] Emit more informative message on connection refused [maven-resolver]

[via GitHub]

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

   By default HTTP Client is quite muted, message is "ConnectException".
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-429


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

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

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

[jira] [Closed] (MJAVADOC-646) Look for javadoc binary in the PATH as well

[Michael Osipov (Jira)]

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

Michael Osipov closed MJAVADOC-646.
---
Fix Version/s: (was: waiting-for-feedback)
   Resolution: Not A Problem

> Look for javadoc binary in the PATH as well
> ---
>
> Key: MJAVADOC-646
> URL: https://issues.apache.org/jira/browse/MJAVADOC-646
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Antonin Delpeuch
>Priority: Minor
>
> Currently, the maven-javadoc-plugin tries to locate the javadoc binary as 
> follows:
>  * either the path to the javadoc executable has been set by the user in the 
> configuration;
>  * or we look for it in the directory designated by the `java.home` system 
> property
>  * or we look for it in the directory designated by the `JAVA_HOME` 
> environment variable
> If none of these work, we fail with the message "Unable to find javadoc 
> command".
> In some environments, such as on Debian Sid with OpenJDK 12, the JAVA_HOME 
> property is not used by default and the javadoc binary is actually located in 
> the PATH, at `/usr/bin/javadoc`. This is a problem: as a user, my options are 
> to manually symlink that javadoc into the installation folder of the JDK (not 
> great) or write down the `/usr/bin/javadoc` path in the plugin's 
> configuration (which is going to lead to failures in other environments).
> This problem seems to be fairly common:
> [https://stackoverflow.com/questions/13961615/unable-to-find-javadoc-command-maven]
> [https://stackoverflow.com/questions/49472783/maven-is-unable-to-find-javadoc-command]
> [https://mail-archives.apache.org/mod_mbox/maven-dev/202003.mbox/browser]
> Therefore I propose to adapt to look for the javadoc binary in the PATH as a 
> last resort attempt, before failing.
> I can do a pull request for this if given the assurance that this is 
> something you would be happy to have.



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

[jira] [Commented] (MJAVADOC-646) Look for javadoc binary in the PATH as well

[Antonin Delpeuch (Jira)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789990#comment-17789990
 ] 

Antonin Delpeuch commented on MJAVADOC-646:
---

I don't have this problem anymore, but I am not sure what the resolution was. I 
think this can be closed.

> Look for javadoc binary in the PATH as well
> ---
>
> Key: MJAVADOC-646
> URL: https://issues.apache.org/jira/browse/MJAVADOC-646
> Project: Maven Javadoc Plugin
>  Issue Type: Improvement
>  Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Antonin Delpeuch
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> Currently, the maven-javadoc-plugin tries to locate the javadoc binary as 
> follows:
>  * either the path to the javadoc executable has been set by the user in the 
> configuration;
>  * or we look for it in the directory designated by the `java.home` system 
> property
>  * or we look for it in the directory designated by the `JAVA_HOME` 
> environment variable
> If none of these work, we fail with the message "Unable to find javadoc 
> command".
> In some environments, such as on Debian Sid with OpenJDK 12, the JAVA_HOME 
> property is not used by default and the javadoc binary is actually located in 
> the PATH, at `/usr/bin/javadoc`. This is a problem: as a user, my options are 
> to manually symlink that javadoc into the installation folder of the JDK (not 
> great) or write down the `/usr/bin/javadoc` path in the plugin's 
> configuration (which is going to lead to failures in other environments).
> This problem seems to be fairly common:
> [https://stackoverflow.com/questions/13961615/unable-to-find-javadoc-command-maven]
> [https://stackoverflow.com/questions/49472783/maven-is-unable-to-find-javadoc-command]
> [https://mail-archives.apache.org/mod_mbox/maven-dev/202003.mbox/browser]
> Therefore I propose to adapt to look for the javadoc binary in the PATH as a 
> last resort attempt, before failing.
> I can do a pull request for this if given the assurance that this is 
> something you would be happy to have.



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

[jira] [Commented] (MCOMPILER-560) Circular dependency is allowed?

[Michael Osipov (Jira)]

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

Michael Osipov commented on MCOMPILER-560:
--

Then you should create a reproducer for someone to look at otherwise it will be 
dormant for years.

> Circular dependency is allowed?
> ---
>
> Key: MCOMPILER-560
> URL: https://issues.apache.org/jira/browse/MCOMPILER-560
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: mikael petterson
>Priority: Major
>
> Hi,
> We are building the following in Eclipse with m2e plugin:
> product A
> -- module1
> -- module2 has dependency to lib1
> -- module3
>    --- this module contains com.company.interfaces.ManagedAbstraction
>    
> lib1 
>  -- dependency to module3 class com.company.interfaces.ManagedAbstraction 
> from com.company.lib1.helpers.HelperBase. Dependency is set as 'provided' in 
> it's repo's pom.xml
> When I build product A in Eclipse with m2e plugin I get the error message:
> The type com.company.interfaces.ManagedAbstraction cannot be resolved. It is 
> indirectly referenced from required type 
> com.company.lib1.helpers.HelperBase
> but it is not visible when I build with:
> mvn clean compile
> The above command is not giving any issues.
> Matbe there is a reasonable explanation for it?
> //mike
>  



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

[jira] [Commented] (MCOMPILER-560) Circular dependency is allowed?

[mikael petterson (Jira)]

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

mikael petterson commented on MCOMPILER-560:


Seems like a bug to me. 

> Circular dependency is allowed?
> ---
>
> Key: MCOMPILER-560
> URL: https://issues.apache.org/jira/browse/MCOMPILER-560
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: mikael petterson
>Priority: Major
>
> Hi,
> We are building the following in Eclipse with m2e plugin:
> product A
> -- module1
> -- module2 has dependency to lib1
> -- module3
>    --- this module contains com.company.interfaces.ManagedAbstraction
>    
> lib1 
>  -- dependency to module3 class com.company.interfaces.ManagedAbstraction 
> from com.company.lib1.helpers.HelperBase. Dependency is set as 'provided' in 
> it's repo's pom.xml
> When I build product A in Eclipse with m2e plugin I get the error message:
> The type com.company.interfaces.ManagedAbstraction cannot be resolved. It is 
> indirectly referenced from required type 
> com.company.lib1.helpers.HelperBase
> but it is not visible when I build with:
> mvn clean compile
> The above command is not giving any issues.
> Matbe there is a reasonable explanation for it?
> //mike
>  



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

[jira] [Commented] (MCOMPILER-560) Circular dependency is allowed?

[Michael Osipov (Jira)]

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

Michael Osipov commented on MCOMPILER-560:
--

Are you reporting a bug or you have a question? Questions go to the users 
mailing list...

> Circular dependency is allowed?
> ---
>
> Key: MCOMPILER-560
> URL: https://issues.apache.org/jira/browse/MCOMPILER-560
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: mikael petterson
>Priority: Major
>
> Hi,
> We are building the following in Eclipse with m2e plugin:
> product A
> -- module1
> -- module2 has dependency to lib1
> -- module3
>    --- this module contains com.company.interfaces.ManagedAbstraction
>    
> lib1 
>  -- dependency to module3 class com.company.interfaces.ManagedAbstraction 
> from com.company.lib1.helpers.HelperBase. Dependency is set as 'provided' in 
> it's repo's pom.xml
> When I build product A in Eclipse with m2e plugin I get the error message:
> The type com.company.interfaces.ManagedAbstraction cannot be resolved. It is 
> indirectly referenced from required type 
> com.company.lib1.helpers.HelperBase
> but it is not visible when I build with:
> mvn clean compile
> The above command is not giving any issues.
> Matbe there is a reasonable explanation for it?
> //mike
>  



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

[jira] [Commented] (DOXIASITETOOLS-320) Inconsistent anchors between toc macro and headers

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/DOXIASITETOOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789956#comment-17789956
 ] 

Konrad Windszus commented on DOXIASITETOOLS-320:


bq. User wants anchors by default, regardless of the TOC

I don't think this is related to this issue, but we can introduce some flag to 
enable this independent of the TOC macro

bq. It will do nothing or overwrite if the user creates anchors by himself, 
e.g., Apt does not: 
https://maven.apache.org/doxia/references/doxia-apt.html#Anchors_for_section_titles

I think APT and XHTML are the only source formats which supports generating 
anchors natively. We should probably add some validation steps which checks for 
duplicates and warn accordingly (automatically fixing/deduplicating is IMHO too 
complicated/dangerous) as this may have subtle effects on CSS styling

bq. What about reports? Do we require that the report plugin author will use 
AbstractMavenReportRenderer to have anchors generated by defaultc or do you 
consider it to be their problem since this is about handwritted docs only?

I am not sure I understand this remark, IMHO anchor generation should happen 
when writing to the sink, therefore it should not really matter what the source 
is (as long as Sink API is used).

> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIASITETOOLS-320
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-320
> Project: Maven Doxia Sitetools
>  Issue Type: Bug
>  Components: Site renderer
>Reporter: Slawomir Jaranowski
>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)

[jira] [Commented] (MASSEMBLY-1011) Bump maven-archiver from 3.6.0 to 3.6.1

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789954#comment-17789954
 ] 

ASF GitHub Bot commented on MASSEMBLY-1011:
---

slawekjaranowski opened a new pull request, #169:
URL: https://github.com/apache/maven-assembly-plugin/pull/169

   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MASSEMBLY) filed 
  for the change (usually before you start working on it).  Trivial 
changes like typos do not 
  require a JIRA issue.  Your pull request should address just this 
issue, without 
  pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[MASSEMBLY-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MASSEMBLY-XXX` with the appropriate JIRA issue. 
Best practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the 
  commit message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
- [x] You have run the integration tests successfully (`mvn -Prun-its clean 
verify`).
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [x] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   




> Bump maven-archiver from 3.6.0 to 3.6.1
> ---
>
> Key: MASSEMBLY-1011
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1011
> Project: Maven Assembly Plugin
>  Issue Type: Dependency upgrade
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: next-release
>
>




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

[PR] [MASSEMBLY-1011] Bump maven-archiver from 3.6.0 to 3.6.1 [maven-assembly-plugin]

[via GitHub]

slawekjaranowski opened a new pull request, #169:
URL: https://github.com/apache/maven-assembly-plugin/pull/169

   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MASSEMBLY) filed 
  for the change (usually before you start working on it).  Trivial 
changes like typos do not 
  require a JIRA issue.  Your pull request should address just this 
issue, without 
  pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[MASSEMBLY-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MASSEMBLY-XXX` with the appropriate JIRA issue. 
Best practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the 
  commit message.
- [ ] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
- [x] You have run the integration tests successfully (`mvn -Prun-its clean 
verify`).
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [x] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   


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

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

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