[ANN] Maven Release 3.1.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Release version 3.1.1.


https://maven.apache.org/maven-release/


Release Notes - Maven Release - Version 3.1.1

** Bug
* [MRELEASE-1149] - Current release of the plugin has configuration 
docs missing
* [MRELEASE-1151] - [REGRESSION] Maven Release Plugin fails to 
adjust version


** Task
* [MRELEASE-1153] - Revert parts of MRELEASE-1109 
(8dfcb47996320af5e6f0b2d50eac209eeb4c29ce) due to a regression



Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Project Info Reports Plugin 3.6.2 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Project Info Reports Plugin version 3.6.2.


https://maven.apache.org/plugins/maven-project-info-reports-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-project-info-reports-plugin
  3.6.2



Release Notes - Maven Project Info Reports Plugin - Version 3.6.2

** Bug
* [MPIR-466] - ModulesReport/IndexReport do not pass a complete 
building request to renderer



Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven PMD Plugin 3.24.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
PMD Plugin version 3.24.0.


https://maven.apache.org/plugins/maven-pmd-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-pmd-plugin
  3.24.0



Release Notes - Maven PMD Plugin - Version 3.24.0

** Bug
* [MPMD-399] - Incorrect warning: The project X does not seem to be 
compiled. PMD results might be inaccurate.


** Improvement
* [MPMD-391] - Log what developers care about and not what they don't

** Dependency upgrade
* [MPMD-400] - Upgrade to PMD 7.3.0


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Indexer 7.1.4 released

[Tamás Cservenák]

The Apache Maven team is pleased to announce the release of the
Maven Indexer 7.1.4

https://maven.apache.org/maven-indexer/

Release Notes - Maven Indexer - Version 7.1.4

** Dependency upgrade
* [MINDEXER-224] - Bump com.google.code.gson:gson from 2.10.1 to 2.11.0
* [MINDEXER-226] - Bump lucene.version from 9.10.0 to 9.11.0
* [MINDEXER-227] - Bump org.eclipse.sisu:org.eclipse.sisu.inject from
0.9.0.M2 to 0.9.0.M3
* [MINDEXER-228] - Bump com.google.guava:guava from 33.2.0-jre to
33.2.1-jre
* [MINDEXER-229] - Bump commons-cli:commons-cli from 1.7.0 to 1.8.0
* [MINDEXER-230] - (build) Bump org.gaul:modernizer-maven-plugin from
2.8.0 to 2.9.0
* [MINDEXER-233] - Bump lucene.version from 9.11.0 to 9.11.1
* [MINDEXER-234] - Bump maven.version from 3.9.6 to 3.9.8
* [MINDEXER-236] - (test) Update Jetty to 10.0.22

Have fun,
-The Apache Maven team

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tamás Cservenák]

Created PR https://github.com/apache/tika/pull/1855

On Wed, Jul 10, 2024 at 11:07 PM Tamás Cservenák 
wrote:

> Created https://issues.apache.org/jira/browse/MNG-8180
>
> On Wed, Jul 10, 2024 at 11:04 PM Tamás Cservenák 
> wrote:
>
>> You, Maven says this:
>>
>> ```
>> [DEBUG] Using transporter HttpTransporter with priority 5.0 for
>> https://repository.apache.org/service/local/staging/deploy/maven2
>> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
>> https://repository.apache.org/service/local/staging/deploy/maven2 with
>> username=cstamas, password=***
>> Uploading to apache.releases.https:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.pom
>> Uploaded to apache.releases.https:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.pom
>> (16 kB at 7.3 kB/s)
>> Uploading to apache.releases.https:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.jar
>> Uploaded to apache.releases.https:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.jar
>> (72 MB at 15 MB/s)
>> Downloading from apache.releases.https:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
>> [DEBUG] Could not find metadata
>> org.apache.tika:tika-grpc/maven-metadata.xml in apache.releases.https (
>> https://repository.apache.org/service/local/staging/deploy/maven2)
>> [DEBUG] Writing tracking file
>> '/home/cstamas/.m2/repository-oss/org/apache/tika/tika-grpc/resolver-status.properties'
>> Uploading to apache.releases.https:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
>> Uploaded to apache.releases.https:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
>> (304 B at 769 B/s)
>> [INFO]
>> 
>> [INFO] BUILD SUCCESS
>> [INFO]
>> 
>> [INFO] Total time:  29.370 s
>> [INFO] Finished at: 2024-07-10T23:01:08+02:00
>> [INFO]
>> 
>> ```
>>
>> And "fake" tika-grpc successfully deployed here:
>> orgapachetika-1104
>>
>> (will drop it)
>>
>> This is a nasty bug.
>>
>> In short, tika-grpc JAR is shaded, and _contains a Maven Plugin_
>> (META-INF/maven/plugin.xml), and Resolver blindly assumed it is deploying
>> _a Maven Plugin_ (based on presence of this file) and took G:A from it and
>> wanted to update plugin metadata
>>
>> Fix:
>> add this line to shade excludes:
>> META-INF/maven/plugin.xml
>>
>> T
>>
>>
>> On Wed, Jul 10, 2024 at 10:57 PM Tamás Cservenák 
>> wrote:
>>
>>> Found it, will create PR and explain
>>>
>>> T
>>>
>>> On Wed, Jul 10, 2024 at 10:22 PM Tim Allison 
>>> wrote:
>>>
 What?!

 On Wed, Jul 10, 2024 at 4:20 PM Tamás Cservenák 
 wrote:

 > Howdy,
 >
 > reproduced, and is even weirder:
 >
 >
 https://gist.github.com/cstamas/4f2e9e68f35da850be60e44c24bc581a#file-gistfile1-txt-L70
 >
 > Line 70 is what you mention...
 >
 > But not only that, you have the same stuff INSTALLed as well, see
 line 32!
 > Looking more...
 >
 >
 > On Wed, Jul 10, 2024 at 9:44 PM Tim Allison 
 wrote:
 >
 > > Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
 > > Maven home: /apache/apache-maven-3.9.7
 > > Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
 > > /usr/lib/jvm/temurin-11-jdk-amd64
 > > Default locale: en_US, platform encoding: UTF-8
 > > OS name: "linux", version: "6.5.0-41-generic", arch: "amd64",
 family:
 > > "unix"
 > >
 > > I've downgraded the version of the deploy plugin for now. I'll let
 you
 > know
 > > if that works. Thank you!
 > >
 > > On Wed, Jul 10, 2024 at 3:37 PM Tamás Cservenák <
 ta...@cservenak.net>
 > > wrote:
 > >
 > > > Howdy,
 > > >
 > > > This is wierd. What maven version are you using? And what java
 version?
 > > > Will try to reproduce.
 > > >
 > > > T
 > > >
 > > > On Wed, Jul 10, 2024, 20:56 Tim Allison 
 wrote:
 > > >
 > > > > Hi All,
 > > > >   I'm sure this is user error. I recently tried to deploy
 Apache Tika
 > > > with
 > > > > maven-deploy-plugin:3.1.2.
 > > > > I'm having a problem with deploying a new module we just added.
 > > > >
 > > > > Our repo is here: https://github.com/apache/tika
 > > > >
 > > > > I see the usual download/upload pattern, but then after the
 final
 > > > download
 > > > > of tika-grpc/metadata.xml, it looks like it is 

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tamás Cservenák]

Created https://issues.apache.org/jira/browse/MNG-8180

On Wed, Jul 10, 2024 at 11:04 PM Tamás Cservenák 
wrote:

> You, Maven says this:
>
> ```
> [DEBUG] Using transporter HttpTransporter with priority 5.0 for
> https://repository.apache.org/service/local/staging/deploy/maven2
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://repository.apache.org/service/local/staging/deploy/maven2 with
> username=cstamas, password=***
> Uploading to apache.releases.https:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.pom
> Uploaded to apache.releases.https:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.pom
> (16 kB at 7.3 kB/s)
> Uploading to apache.releases.https:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.jar
> Uploaded to apache.releases.https:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.jar
> (72 MB at 15 MB/s)
> Downloading from apache.releases.https:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
> [DEBUG] Could not find metadata
> org.apache.tika:tika-grpc/maven-metadata.xml in apache.releases.https (
> https://repository.apache.org/service/local/staging/deploy/maven2)
> [DEBUG] Writing tracking file
> '/home/cstamas/.m2/repository-oss/org/apache/tika/tika-grpc/resolver-status.properties'
> Uploading to apache.releases.https:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
> Uploaded to apache.releases.https:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
> (304 B at 769 B/s)
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time:  29.370 s
> [INFO] Finished at: 2024-07-10T23:01:08+02:00
> [INFO]
> 
> ```
>
> And "fake" tika-grpc successfully deployed here:
> orgapachetika-1104
>
> (will drop it)
>
> This is a nasty bug.
>
> In short, tika-grpc JAR is shaded, and _contains a Maven Plugin_
> (META-INF/maven/plugin.xml), and Resolver blindly assumed it is deploying
> _a Maven Plugin_ (based on presence of this file) and took G:A from it and
> wanted to update plugin metadata
>
> Fix:
> add this line to shade excludes:
> META-INF/maven/plugin.xml
>
> T
>
>
> On Wed, Jul 10, 2024 at 10:57 PM Tamás Cservenák 
> wrote:
>
>> Found it, will create PR and explain
>>
>> T
>>
>> On Wed, Jul 10, 2024 at 10:22 PM Tim Allison  wrote:
>>
>>> What?!
>>>
>>> On Wed, Jul 10, 2024 at 4:20 PM Tamás Cservenák 
>>> wrote:
>>>
>>> > Howdy,
>>> >
>>> > reproduced, and is even weirder:
>>> >
>>> >
>>> https://gist.github.com/cstamas/4f2e9e68f35da850be60e44c24bc581a#file-gistfile1-txt-L70
>>> >
>>> > Line 70 is what you mention...
>>> >
>>> > But not only that, you have the same stuff INSTALLed as well, see line
>>> 32!
>>> > Looking more...
>>> >
>>> >
>>> > On Wed, Jul 10, 2024 at 9:44 PM Tim Allison 
>>> wrote:
>>> >
>>> > > Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
>>> > > Maven home: /apache/apache-maven-3.9.7
>>> > > Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
>>> > > /usr/lib/jvm/temurin-11-jdk-amd64
>>> > > Default locale: en_US, platform encoding: UTF-8
>>> > > OS name: "linux", version: "6.5.0-41-generic", arch: "amd64", family:
>>> > > "unix"
>>> > >
>>> > > I've downgraded the version of the deploy plugin for now. I'll let
>>> you
>>> > know
>>> > > if that works. Thank you!
>>> > >
>>> > > On Wed, Jul 10, 2024 at 3:37 PM Tamás Cservenák >> >
>>> > > wrote:
>>> > >
>>> > > > Howdy,
>>> > > >
>>> > > > This is wierd. What maven version are you using? And what java
>>> version?
>>> > > > Will try to reproduce.
>>> > > >
>>> > > > T
>>> > > >
>>> > > > On Wed, Jul 10, 2024, 20:56 Tim Allison 
>>> wrote:
>>> > > >
>>> > > > > Hi All,
>>> > > > >   I'm sure this is user error. I recently tried to deploy Apache
>>> Tika
>>> > > > with
>>> > > > > maven-deploy-plugin:3.1.2.
>>> > > > > I'm having a problem with deploying a new module we just added.
>>> > > > >
>>> > > > > Our repo is here: https://github.com/apache/tika
>>> > > > >
>>> > > > > I see the usual download/upload pattern, but then after the final
>>> > > > download
>>> > > > > of tika-grpc/metadata.xml, it looks like it is trying to
>>> download the
>>> > > > > metadata for xmlbeans?!
>>> > > > >
>>> > > > > What am I doing wrong?
>>> > > > >
>>> > > > > Thank you!
>>> > > > >
>>> > > > > Expected pattern:
>>> > > > >
>>> > > > > [INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @
>>> tika-grpc
>>> 

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tamás Cservenák]

You, Maven says this:

```
[DEBUG] Using transporter HttpTransporter with priority 5.0 for
https://repository.apache.org/service/local/staging/deploy/maven2
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://repository.apache.org/service/local/staging/deploy/maven2 with
username=cstamas, password=***
Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.pom
Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.pom
(16 kB at 7.3 kB/s)
Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.jar
Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0/tika-grpc-3.0.0.jar
(72 MB at 15 MB/s)
Downloading from apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.tika:tika-grpc/maven-metadata.xml in apache.releases.https (
https://repository.apache.org/service/local/staging/deploy/maven2)
[DEBUG] Writing tracking file
'/home/cstamas/.m2/repository-oss/org/apache/tika/tika-grpc/resolver-status.properties'
Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
(304 B at 769 B/s)
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time:  29.370 s
[INFO] Finished at: 2024-07-10T23:01:08+02:00
[INFO]

```

And "fake" tika-grpc successfully deployed here:
orgapachetika-1104

(will drop it)

This is a nasty bug.

In short, tika-grpc JAR is shaded, and _contains a Maven Plugin_
(META-INF/maven/plugin.xml), and Resolver blindly assumed it is deploying
_a Maven Plugin_ (based on presence of this file) and took G:A from it and
wanted to update plugin metadata

Fix:
add this line to shade excludes:
META-INF/maven/plugin.xml

T


On Wed, Jul 10, 2024 at 10:57 PM Tamás Cservenák 
wrote:

> Found it, will create PR and explain
>
> T
>
> On Wed, Jul 10, 2024 at 10:22 PM Tim Allison  wrote:
>
>> What?!
>>
>> On Wed, Jul 10, 2024 at 4:20 PM Tamás Cservenák 
>> wrote:
>>
>> > Howdy,
>> >
>> > reproduced, and is even weirder:
>> >
>> >
>> https://gist.github.com/cstamas/4f2e9e68f35da850be60e44c24bc581a#file-gistfile1-txt-L70
>> >
>> > Line 70 is what you mention...
>> >
>> > But not only that, you have the same stuff INSTALLed as well, see line
>> 32!
>> > Looking more...
>> >
>> >
>> > On Wed, Jul 10, 2024 at 9:44 PM Tim Allison 
>> wrote:
>> >
>> > > Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
>> > > Maven home: /apache/apache-maven-3.9.7
>> > > Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
>> > > /usr/lib/jvm/temurin-11-jdk-amd64
>> > > Default locale: en_US, platform encoding: UTF-8
>> > > OS name: "linux", version: "6.5.0-41-generic", arch: "amd64", family:
>> > > "unix"
>> > >
>> > > I've downgraded the version of the deploy plugin for now. I'll let you
>> > know
>> > > if that works. Thank you!
>> > >
>> > > On Wed, Jul 10, 2024 at 3:37 PM Tamás Cservenák 
>> > > wrote:
>> > >
>> > > > Howdy,
>> > > >
>> > > > This is wierd. What maven version are you using? And what java
>> version?
>> > > > Will try to reproduce.
>> > > >
>> > > > T
>> > > >
>> > > > On Wed, Jul 10, 2024, 20:56 Tim Allison 
>> wrote:
>> > > >
>> > > > > Hi All,
>> > > > >   I'm sure this is user error. I recently tried to deploy Apache
>> Tika
>> > > > with
>> > > > > maven-deploy-plugin:3.1.2.
>> > > > > I'm having a problem with deploying a new module we just added.
>> > > > >
>> > > > > Our repo is here: https://github.com/apache/tika
>> > > > >
>> > > > > I see the usual download/upload pattern, but then after the final
>> > > > download
>> > > > > of tika-grpc/metadata.xml, it looks like it is trying to download
>> the
>> > > > > metadata for xmlbeans?!
>> > > > >
>> > > > > What am I doing wrong?
>> > > > >
>> > > > > Thank you!
>> > > > >
>> > > > > Expected pattern:
>> > > > >
>> > > > > [INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @ tika-grpc
>> > ---
>> > > > > [INFO] Uploading to apache.releases.https:
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
>> > > > > [INFO] Progress (1): 16 kB
>> > > > > [INFO]
>> > > > > [INFO] Uploaded 

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tamás Cservenák]

Found it, will create PR and explain

T

On Wed, Jul 10, 2024 at 10:22 PM Tim Allison  wrote:

> What?!
>
> On Wed, Jul 10, 2024 at 4:20 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > reproduced, and is even weirder:
> >
> >
> https://gist.github.com/cstamas/4f2e9e68f35da850be60e44c24bc581a#file-gistfile1-txt-L70
> >
> > Line 70 is what you mention...
> >
> > But not only that, you have the same stuff INSTALLed as well, see line
> 32!
> > Looking more...
> >
> >
> > On Wed, Jul 10, 2024 at 9:44 PM Tim Allison  wrote:
> >
> > > Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> > > Maven home: /apache/apache-maven-3.9.7
> > > Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
> > > /usr/lib/jvm/temurin-11-jdk-amd64
> > > Default locale: en_US, platform encoding: UTF-8
> > > OS name: "linux", version: "6.5.0-41-generic", arch: "amd64", family:
> > > "unix"
> > >
> > > I've downgraded the version of the deploy plugin for now. I'll let you
> > know
> > > if that works. Thank you!
> > >
> > > On Wed, Jul 10, 2024 at 3:37 PM Tamás Cservenák 
> > > wrote:
> > >
> > > > Howdy,
> > > >
> > > > This is wierd. What maven version are you using? And what java
> version?
> > > > Will try to reproduce.
> > > >
> > > > T
> > > >
> > > > On Wed, Jul 10, 2024, 20:56 Tim Allison  wrote:
> > > >
> > > > > Hi All,
> > > > >   I'm sure this is user error. I recently tried to deploy Apache
> Tika
> > > > with
> > > > > maven-deploy-plugin:3.1.2.
> > > > > I'm having a problem with deploying a new module we just added.
> > > > >
> > > > > Our repo is here: https://github.com/apache/tika
> > > > >
> > > > > I see the usual download/upload pattern, but then after the final
> > > > download
> > > > > of tika-grpc/metadata.xml, it looks like it is trying to download
> the
> > > > > metadata for xmlbeans?!
> > > > >
> > > > > What am I doing wrong?
> > > > >
> > > > > Thank you!
> > > > >
> > > > > Expected pattern:
> > > > >
> > > > > [INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @ tika-grpc
> > ---
> > > > > [INFO] Uploading to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> > > > > [INFO] Progress (1): 16 kB
> > > > > [INFO]
> > > > > [INFO] Uploaded to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> > > > > (16 kB at 9.0 kB/s)
> > > > > [INFO] Uploading to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> > > > > [INFO] Uploading to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> > > > > [INFO] Uploading to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> > > > > [INFO] Uploading to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> > > > > [INFO] Uploading to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> > > > > 
> > > > >
> > > > > [INFO] Uploaded to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> > > > > (833 B at 1.2 kB/s)
> > > > > [INFO] Uploaded to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> > > > > (833 B at 1.2 kB/s)
> > > > > [INFO] Uploaded to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> > > > > (833 B at 1.2 kB/s)
> > > > > 
> > > > >
> > > > > [INFO] Uploaded to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> > > > > (82 kB at 53 kB/s)
> > > > >
> > > > > 
> > > > >
> > > > > [INFO] Uploaded to apache.releases.https:
> > > > >
> > > > >
> > > >
> > >
> >
> 

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tim Allison]

What?!

On Wed, Jul 10, 2024 at 4:20 PM Tamás Cservenák  wrote:

> Howdy,
>
> reproduced, and is even weirder:
>
> https://gist.github.com/cstamas/4f2e9e68f35da850be60e44c24bc581a#file-gistfile1-txt-L70
>
> Line 70 is what you mention...
>
> But not only that, you have the same stuff INSTALLed as well, see line 32!
> Looking more...
>
>
> On Wed, Jul 10, 2024 at 9:44 PM Tim Allison  wrote:
>
> > Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> > Maven home: /apache/apache-maven-3.9.7
> > Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
> > /usr/lib/jvm/temurin-11-jdk-amd64
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "6.5.0-41-generic", arch: "amd64", family:
> > "unix"
> >
> > I've downgraded the version of the deploy plugin for now. I'll let you
> know
> > if that works. Thank you!
> >
> > On Wed, Jul 10, 2024 at 3:37 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > This is wierd. What maven version are you using? And what java version?
> > > Will try to reproduce.
> > >
> > > T
> > >
> > > On Wed, Jul 10, 2024, 20:56 Tim Allison  wrote:
> > >
> > > > Hi All,
> > > >   I'm sure this is user error. I recently tried to deploy Apache Tika
> > > with
> > > > maven-deploy-plugin:3.1.2.
> > > > I'm having a problem with deploying a new module we just added.
> > > >
> > > > Our repo is here: https://github.com/apache/tika
> > > >
> > > > I see the usual download/upload pattern, but then after the final
> > > download
> > > > of tika-grpc/metadata.xml, it looks like it is trying to download the
> > > > metadata for xmlbeans?!
> > > >
> > > > What am I doing wrong?
> > > >
> > > > Thank you!
> > > >
> > > > Expected pattern:
> > > >
> > > > [INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @ tika-grpc
> ---
> > > > [INFO] Uploading to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> > > > [INFO] Progress (1): 16 kB
> > > > [INFO]
> > > > [INFO] Uploaded to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> > > > (16 kB at 9.0 kB/s)
> > > > [INFO] Uploading to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> > > > [INFO] Uploading to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> > > > [INFO] Uploading to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> > > > [INFO] Uploading to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> > > > [INFO] Uploading to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> > > > 
> > > >
> > > > [INFO] Uploaded to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> > > > (833 B at 1.2 kB/s)
> > > > [INFO] Uploaded to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> > > > (833 B at 1.2 kB/s)
> > > > [INFO] Uploaded to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> > > > (833 B at 1.2 kB/s)
> > > > 
> > > >
> > > > [INFO] Uploaded to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> > > > (82 kB at 53 kB/s)
> > > >
> > > > 
> > > >
> > > > [INFO] Uploaded to apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> > > > (72 MB at 6.2 MB/s)
> > > > [INFO] Downloading from apache.releases.https:
> > > >
> > > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
> > > > *[INFO] Downloading from apache.releases.https:
> > > >
> > > >
> > >
> >
> 

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tim Allison]

Sorry, should have been dev@tika earlier, not private@tika.

I rolled back the deploy-plugin to 3.1.1, which was successful for our last
deployment of 2.9.2. That worked then. It does not work now with this new
tika-grpc module.

On Wed, Jul 10, 2024 at 3:42 PM Tim Allison  wrote:

> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /apache/apache-maven-3.9.7
> Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
> /usr/lib/jvm/temurin-11-jdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.5.0-41-generic", arch: "amd64", family:
> "unix"
>
> I've downgraded the version of the deploy plugin for now. I'll let you
> know if that works. Thank you!
>
> On Wed, Jul 10, 2024 at 3:37 PM Tamás Cservenák 
> wrote:
>
>> Howdy,
>>
>> This is wierd. What maven version are you using? And what java version?
>> Will try to reproduce.
>>
>> T
>>
>> On Wed, Jul 10, 2024, 20:56 Tim Allison  wrote:
>>
>> > Hi All,
>> >   I'm sure this is user error. I recently tried to deploy Apache Tika
>> with
>> > maven-deploy-plugin:3.1.2.
>> > I'm having a problem with deploying a new module we just added.
>> >
>> > Our repo is here: https://github.com/apache/tika
>> >
>> > I see the usual download/upload pattern, but then after the final
>> download
>> > of tika-grpc/metadata.xml, it looks like it is trying to download the
>> > metadata for xmlbeans?!
>> >
>> > What am I doing wrong?
>> >
>> > Thank you!
>> >
>> > Expected pattern:
>> >
>> > [INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @ tika-grpc ---
>> > [INFO] Uploading to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
>> > [INFO] Progress (1): 16 kB
>> > [INFO]
>> > [INFO] Uploaded to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
>> > (16 kB at 9.0 kB/s)
>> > [INFO] Uploading to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
>> > [INFO] Uploading to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
>> > [INFO] Uploading to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
>> > [INFO] Uploading to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
>> > [INFO] Uploading to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
>> > 
>> >
>> > [INFO] Uploaded to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
>> > (833 B at 1.2 kB/s)
>> > [INFO] Uploaded to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
>> > (833 B at 1.2 kB/s)
>> > [INFO] Uploaded to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
>> > (833 B at 1.2 kB/s)
>> > 
>> >
>> > [INFO] Uploaded to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
>> > (82 kB at 53 kB/s)
>> >
>> > 
>> >
>> > [INFO] Uploaded to apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
>> > (72 MB at 6.2 MB/s)
>> > [INFO] Downloading from apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
>> > *[INFO] Downloading from apache.releases.https:
>> >
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
>> > <
>> >
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
>> > >*
>> > [INFO] [WARNING] Could not transfer metadata
>> > org.apache.xmlbeans/maven-metadata.xml from/to apache.releases.https (
>> > https://repository.apache.org/service/local/staging/deploy/maven2):
>> status
>> > code: 400, reason phrase: Bad Request (400)
>> >
>>
>

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tamás Cservenák]

Howdy,

reproduced, and is even weirder:
https://gist.github.com/cstamas/4f2e9e68f35da850be60e44c24bc581a#file-gistfile1-txt-L70

Line 70 is what you mention...

But not only that, you have the same stuff INSTALLed as well, see line 32!
Looking more...


On Wed, Jul 10, 2024 at 9:44 PM Tim Allison  wrote:

> Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /apache/apache-maven-3.9.7
> Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
> /usr/lib/jvm/temurin-11-jdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.5.0-41-generic", arch: "amd64", family:
> "unix"
>
> I've downgraded the version of the deploy plugin for now. I'll let you know
> if that works. Thank you!
>
> On Wed, Jul 10, 2024 at 3:37 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > This is wierd. What maven version are you using? And what java version?
> > Will try to reproduce.
> >
> > T
> >
> > On Wed, Jul 10, 2024, 20:56 Tim Allison  wrote:
> >
> > > Hi All,
> > >   I'm sure this is user error. I recently tried to deploy Apache Tika
> > with
> > > maven-deploy-plugin:3.1.2.
> > > I'm having a problem with deploying a new module we just added.
> > >
> > > Our repo is here: https://github.com/apache/tika
> > >
> > > I see the usual download/upload pattern, but then after the final
> > download
> > > of tika-grpc/metadata.xml, it looks like it is trying to download the
> > > metadata for xmlbeans?!
> > >
> > > What am I doing wrong?
> > >
> > > Thank you!
> > >
> > > Expected pattern:
> > >
> > > [INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @ tika-grpc ---
> > > [INFO] Uploading to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> > > [INFO] Progress (1): 16 kB
> > > [INFO]
> > > [INFO] Uploaded to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> > > (16 kB at 9.0 kB/s)
> > > [INFO] Uploading to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> > > [INFO] Uploading to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> > > [INFO] Uploading to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> > > [INFO] Uploading to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> > > [INFO] Uploading to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> > > 
> > >
> > > [INFO] Uploaded to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> > > (833 B at 1.2 kB/s)
> > > [INFO] Uploaded to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> > > (833 B at 1.2 kB/s)
> > > [INFO] Uploaded to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> > > (833 B at 1.2 kB/s)
> > > 
> > >
> > > [INFO] Uploaded to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> > > (82 kB at 53 kB/s)
> > >
> > > 
> > >
> > > [INFO] Uploaded to apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> > > (72 MB at 6.2 MB/s)
> > > [INFO] Downloading from apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
> > > *[INFO] Downloading from apache.releases.https:
> > >
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
> > > <
> > >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
> > > >*
> > > [INFO] [WARNING] Could not transfer metadata
> > > org.apache.xmlbeans/maven-metadata.xml from/to apache.releases.https (
> > > https://repository.apache.org/service/local/staging/deploy/maven2):

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tim Allison]

Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
Maven home: /apache/apache-maven-3.9.7
Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
/usr/lib/jvm/temurin-11-jdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.5.0-41-generic", arch: "amd64", family: "unix"

I've downgraded the version of the deploy plugin for now. I'll let you know
if that works. Thank you!

On Wed, Jul 10, 2024 at 3:37 PM Tamás Cservenák  wrote:

> Howdy,
>
> This is wierd. What maven version are you using? And what java version?
> Will try to reproduce.
>
> T
>
> On Wed, Jul 10, 2024, 20:56 Tim Allison  wrote:
>
> > Hi All,
> >   I'm sure this is user error. I recently tried to deploy Apache Tika
> with
> > maven-deploy-plugin:3.1.2.
> > I'm having a problem with deploying a new module we just added.
> >
> > Our repo is here: https://github.com/apache/tika
> >
> > I see the usual download/upload pattern, but then after the final
> download
> > of tika-grpc/metadata.xml, it looks like it is trying to download the
> > metadata for xmlbeans?!
> >
> > What am I doing wrong?
> >
> > Thank you!
> >
> > Expected pattern:
> >
> > [INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @ tika-grpc ---
> > [INFO] Uploading to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> > [INFO] Progress (1): 16 kB
> > [INFO]
> > [INFO] Uploaded to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> > (16 kB at 9.0 kB/s)
> > [INFO] Uploading to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> > [INFO] Uploading to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> > [INFO] Uploading to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> > [INFO] Uploading to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> > [INFO] Uploading to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> > 
> >
> > [INFO] Uploaded to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> > (833 B at 1.2 kB/s)
> > [INFO] Uploaded to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> > (833 B at 1.2 kB/s)
> > [INFO] Uploaded to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> > (833 B at 1.2 kB/s)
> > 
> >
> > [INFO] Uploaded to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> > (82 kB at 53 kB/s)
> >
> > 
> >
> > [INFO] Uploaded to apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> > (72 MB at 6.2 MB/s)
> > [INFO] Downloading from apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
> > *[INFO] Downloading from apache.releases.https:
> >
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
> > <
> >
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
> > >*
> > [INFO] [WARNING] Could not transfer metadata
> > org.apache.xmlbeans/maven-metadata.xml from/to apache.releases.https (
> > https://repository.apache.org/service/local/staging/deploy/maven2):
> status
> > code: 400, reason phrase: Bad Request (400)
> >
>

Re: maven-deploy pulling extraneous dependency's metadata?!

[Tamás Cservenák]

Howdy,

This is wierd. What maven version are you using? And what java version?
Will try to reproduce.

T

On Wed, Jul 10, 2024, 20:56 Tim Allison  wrote:

> Hi All,
>   I'm sure this is user error. I recently tried to deploy Apache Tika with
> maven-deploy-plugin:3.1.2.
> I'm having a problem with deploying a new module we just added.
>
> Our repo is here: https://github.com/apache/tika
>
> I see the usual download/upload pattern, but then after the final download
> of tika-grpc/metadata.xml, it looks like it is trying to download the
> metadata for xmlbeans?!
>
> What am I doing wrong?
>
> Thank you!
>
> Expected pattern:
>
> [INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @ tika-grpc ---
> [INFO] Uploading to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> [INFO] Progress (1): 16 kB
> [INFO]
> [INFO] Uploaded to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
> (16 kB at 9.0 kB/s)
> [INFO] Uploading to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> [INFO] Uploading to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> [INFO] Uploading to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> [INFO] Uploading to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> [INFO] Uploading to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> 
>
> [INFO] Uploaded to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
> (833 B at 1.2 kB/s)
> [INFO] Uploaded to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
> (833 B at 1.2 kB/s)
> [INFO] Uploaded to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
> (833 B at 1.2 kB/s)
> 
>
> [INFO] Uploaded to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
> (82 kB at 53 kB/s)
>
> 
>
> [INFO] Uploaded to apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
> (72 MB at 6.2 MB/s)
> [INFO] Downloading from apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
> *[INFO] Downloading from apache.releases.https:
>
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
> <
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
> >*
> [INFO] [WARNING] Could not transfer metadata
> org.apache.xmlbeans/maven-metadata.xml from/to apache.releases.https (
> https://repository.apache.org/service/local/staging/deploy/maven2): status
> code: 400, reason phrase: Bad Request (400)
>

[ANN] Maven Surefire 3.3.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Surefire version 3.3.1.


https://maven.apache.org/surefire/


Release Notes - Maven Surefire - Version 3.3.1

** Bug
* [SUREFIRE-2105] - Failsafe report size increased with version 
upgrade from 2.17 to 2.22.2
* [SUREFIRE-2242] - Plain test report does not include names of the 
skipped tests
* [SUREFIRE-2250] - Surefire Test Report Schema properties element 
is not consistent with the code


** Improvement
* [SUREFIRE-1360] - Ability to disable properties for successfully 
passed tests
* [SUREFIRE-1934] - Ability to disable system-out/system-err for 
successfully passed tests
* [SUREFIRE-2124] - Avoid creating unnecessary target files for pom 
projects
* [SUREFIRE-2249] - Doc for `properties` parameter does not mention 
JUnit



Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven-deploy pulling extraneous dependency's metadata?!

[Tim Allison]

Hi All,
  I'm sure this is user error. I recently tried to deploy Apache Tika with
maven-deploy-plugin:3.1.2.
I'm having a problem with deploying a new module we just added.

Our repo is here: https://github.com/apache/tika

I see the usual download/upload pattern, but then after the final download
of tika-grpc/metadata.xml, it looks like it is trying to download the
metadata for xmlbeans?!

What am I doing wrong?

Thank you!

Expected pattern:

[INFO] [INFO] --- deploy:3.1.2:deploy (default-deploy) @ tika-grpc ---
[INFO] Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
[INFO] Progress (1): 16 kB
[INFO]
[INFO] Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom
(16 kB at 9.0 kB/s)
[INFO] Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
[INFO] Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
[INFO] Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
[INFO] Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
[INFO] Uploading to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc


[INFO] Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar.asc
(833 B at 1.2 kB/s)
[INFO] Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.pom.asc
(833 B at 1.2 kB/s)
[INFO] Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar.asc
(833 B at 1.2 kB/s)


[INFO] Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2-sources.jar
(82 kB at 53 kB/s)



[INFO] Uploaded to apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/3.0.0-BETA2/tika-grpc-3.0.0-BETA2.jar
(72 MB at 6.2 MB/s)
[INFO] Downloading from apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/tika/tika-grpc/maven-metadata.xml
*[INFO] Downloading from apache.releases.https:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/xmlbeans/maven-metadata.xml
*
[INFO] [WARNING] Could not transfer metadata
org.apache.xmlbeans/maven-metadata.xml from/to apache.releases.https (
https://repository.apache.org/service/local/staging/deploy/maven2): status
code: 400, reason phrase: Bad Request (400)

[ANN] Apache Maven Parent POMs 43 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Maven
Parent POMs Version 43.

https://maven.apache.org/pom/maven/

You should specify the version in your project as parent like the following:


  org.apache.maven
  maven-parent
  43


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/pom/maven/download.html

Release Notes

## Breaking changes

- Remove dependency on maven-plugin-annotations to better support Maven 4
plugins ([#190](https://github.com/apache/maven-parent/pull/190)) @gnodet
- Remove checkstyle.violation.ignore ([#183](
https://github.com/apache/maven-parent/pull/183)) @slawekjaranowski

## New features and improvements

- Skip render empty taglist report ([#193](
https://github.com/apache/maven-parent/pull/193)) @slawekjaranowski
- [[MNG-8158]](https://issues.apache.org/jira/browse/MNG-8158) - Adding
name to empty components section in shared site left nav ([#188](
https://github.com/apache/maven-parent/pull/188)) @bdemers
- Introduce property for maven-shared-resources version ([#182](
https://github.com/apache/maven-parent/pull/182)) @slawekjaranowski
- Enable GitHUb issues ([#175](
https://github.com/apache/maven-parent/pull/175)) @slawekjaranowski

## Dependency updates

- Bump ASF parent to 33 ([#195](
https://github.com/apache/maven-parent/pull/195)) @slawekjaranowski
- Bump org.codehaus.mojo:taglist-maven-plugin from 3.0.0 to 3.1.0 ([#192](
https://github.com/apache/maven-parent/pull/192)) @dependabot
- Bump org.apache.maven.plugins:maven-pmd-plugin from 3.22.0 to 3.23.0
([#186](https://github.com/apache/maven-parent/pull/186)) @dependabot
- Bump org.apache.maven.shared:maven-shared-resources from 5 to 6 ([#187](
https://github.com/apache/maven-parent/pull/187)) @dependabot
- Upgrade to Maven Fluido Skin 1.12.0 ([#191](
https://github.com/apache/maven-parent/pull/191)) @michael-o
- Bump org.junit:junit-bom from 5.10.2 to 5.10.3 ([#189](
https://github.com/apache/maven-parent/pull/189)) @dependabot
- Bump org.apache.maven.plugins:maven-jxr-plugin from 3.3.2 to 3.4.0
([#185](https://github.com/apache/maven-parent/pull/185)) @dependabot
- Bump version.sisu-maven-plugin from 0.9.0.M2 to 0.9.0.M3 ([#184](
https://github.com/apache/maven-parent/pull/184)) @dependabot
- Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 3.0.1 ([#181](
https://github.com/apache/maven-parent/pull/181)) @dependabot
- Bump org.codehaus.modello:modello-maven-plugin from 2.3.0 to 2.4.0
([#179](https://github.com/apache/maven-parent/pull/179)) @dependabot
- Bump org.apache.maven.plugins:maven-pmd-plugin from 3.21.2 to 3.22.0
([#178](https://github.com/apache/maven-parent/pull/178)) @dependabot
- Bump org.apache.maven.plugins:maven-toolchains-plugin from 3.1.0 to 3.2.0
([#176](https://github.com/apache/maven-parent/pull/176)) @dependabot

## Maintenance

- Fix link in issueManagement in docs ([#177](
https://github.com/apache/maven-parent/pull/177)) @slawekjaranowski

## Build

- Disable matrix build on GitHub ([#194](
https://github.com/apache/maven-parent/pull/194)) @slawekjaranowski
- Add Release Drafter ([#174](
https://github.com/apache/maven-parent/pull/174)) @slawekjaranowski

Enjoy,
-The Apache Maven team

[ANN] Apache Software Foundation Parent POM Version 33 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Software Foundation Parent POM Version, version 33

https://maven.apache.org/pom/asf/

You should specify the version in your project as parent like the following:


  org.apache
  apache
  33


You can download the appropriate sources etc. from the download page:

http://maven.apache.org/pom/asf/download.html

Release Notes

## New features and improvements

- Enable GitHUb issues ([#216](
https://github.com/apache/maven-apache-parent/pull/216)) @slawekjaranowski

## Dependency updates

- Bump org.apache.maven.plugins:maven-dependency-plugin from 3.7.0 to 3.7.1
([#238](https://github.com/apache/maven-apache-parent/pull/238)) @dependabot
- Bump org.apache.maven.plugins:maven-project-info-reports-plugin from
3.5.0 to 3.6.1 ([#239](
https://github.com/apache/maven-apache-parent/pull/239)) @dependabot
- Upgrade to Maven Fluido Skin 1.12.0 ([#240](
https://github.com/apache/maven-apache-parent/pull/240)) @michael-o
- Bump org.apache.maven.plugins:maven-scm-publish-plugin from 3.2.1 to
3.3.0 ([#237](https://github.com/apache/maven-apache-parent/pull/237))
@dependabot
- Bump org.apache.maven.plugins:maven-jar-plugin from 3.4.1 to 3.4.2
([#236](https://github.com/apache/maven-apache-parent/pull/236)) @dependabot
- Bump org.apache.maven.plugins:maven-clean-plugin from 3.3.2 to 3.4.0
([#235](https://github.com/apache/maven-apache-parent/pull/235)) @dependabot
- Bump version.maven-surefire from 3.2.5 to 3.3.0 ([#234](
https://github.com/apache/maven-apache-parent/pull/234)) @dependabot
- Bump org.apache.maven.plugins:maven-release-plugin from 3.0.1 to 3.1.0
([#233](https://github.com/apache/maven-apache-parent/pull/233)) @dependabot
- Bump org.apache.maven.plugins:maven-dependency-plugin from 3.6.1 to 3.7.0
([#231](https://github.com/apache/maven-apache-parent/pull/231)) @dependabot
- Bump org.apache.maven.plugins:maven-help-plugin from 3.4.0 to 3.4.1
([#230](https://github.com/apache/maven-apache-parent/pull/230)) @dependabot
- Bump org.apache.maven.plugins:maven-checkstyle-plugin from 3.3.1 to 3.4.0
([#229](https://github.com/apache/maven-apache-parent/pull/229)) @dependabot
- Bump org.apache.maven.plugins:maven-shade-plugin from 3.5.2 to 3.6.0
([#228](https://github.com/apache/maven-apache-parent/pull/228)) @dependabot
- Bump org.apache.maven.plugins:maven-javadoc-plugin from 3.6.3 to 3.7.0
([#227](https://github.com/apache/maven-apache-parent/pull/227)) @dependabot
- Bump org.apache.maven.plugins:maven-enforcer-plugin from 3.4.1 to 3.5.0
([#225](https://github.com/apache/maven-apache-parent/pull/225)) @dependabot
- Bump version.maven-plugin-tools from 3.12.0 to 3.13.1 ([#226](
https://github.com/apache/maven-apache-parent/pull/226)) @dependabot
- Bump org.apache.maven.plugins:maven-invoker-plugin from 3.6.1 to 3.7.0
([#224](https://github.com/apache/maven-apache-parent/pull/224)) @dependabot
- Bump org.apache.maven.plugins:maven-deploy-plugin from 3.1.1 to 3.1.2
([#221](https://github.com/apache/maven-apache-parent/pull/221)) @dependabot
- Bump org.apache.maven.plugins:maven-gpg-plugin from 3.2.3 to 3.2.4
([#218](https://github.com/apache/maven-apache-parent/pull/218)) @dependabot
- Bump org.apache.maven.plugins:maven-install-plugin from 3.1.1 to 3.1.2
([#222](https://github.com/apache/maven-apache-parent/pull/222)) @dependabot
- Bump org.apache.maven.plugins:maven-jar-plugin from 3.4.0 to 3.4.1
([#217](https://github.com/apache/maven-apache-parent/pull/217)) @dependabot
- Bump org.apache.maven.plugins:maven-scm-plugin from 2.0.1 to 2.1.0
([#214](https://github.com/apache/maven-apache-parent/pull/214)) @dependabot

## Maintenance

- Fix link in issueManagement in docs ([#219](
https://github.com/apache/maven-apache-parent/pull/219)) @slawekjaranowski

## Build

- Disable matrix build on GitHub ([#241](
https://github.com/apache/maven-apache-parent/pull/241)) @slawekjaranowski
- Add Release Drafter ([#215](
https://github.com/apache/maven-apache-parent/pull/215)) @slawekjaranowski

Enjoy,

-The Apache Maven team

[HEADS UP] Maven Doxia 2.0.0 stack is coming

[Michael Osipov]

Dear Users, Reporting Plugin and Skin Maintainers,

for the past 2,5 years we have been working -- that is me (mostly) with 
Hervé Boutemy and Konrad Windszus -- on the modernization of the Doxia 
stack overcoming technical debts and open issues of the past ten years. 
After numerous milestones (10+) it has reached a very good maturity and 
stability to finally move to GA.


What is Maven Doxia anyway? It is the core document generation framework 
on which all Maven reporting plugins and the Maven Site Plugin are built 
upon. So when you invoke a standalone reporting goal or "mvn site" that 
stack is being used.

The involved components and reporting plugins from the Maven Core Team:
* maven-doxia
* maven-reporting-api
* maven-doxia-sitetools
* maven-reporting-impl
* maven-reporting-exec
* maven-site-plugin
* maven-fluido-skin
* maven-project-info-reports-plugin
* maven-plugin-tools (maven-plugin-reporting-plugin)
* maven-jxr (maven-jxr-plugin)
* maven-pmd-plugin
* maven-javadoc-plugin
* maven-checkstyle-plugin
* maven-help-plugin (uses API only)
* maven-surefire (maven-surefire-report-plugin)
* maven-dependency-plugin
* maven-invoker-plugin

Notes:
* Other reporting plugins we provide are not being upgraded
* Third party plugins need to be upgraded by their respective maintainers
* Components do have milestone versions until public evaluation has been 
completed


Also, please see this Confluence Wiki entry for more (technical) 
details: 
https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack


What do you need to do?
* As a user you can build the reporting plugins from the prepared branch 
'doxia-2.0.0' or reach out to the third party maintainer to test his 
plugin against the updated stack.
* As a plugin maintainer you can start upgrading your plugin against the 
2.0.0 baseline in a separate branch. Look at the 'doxia-2.0.0' branch of 
our plugins to ease your work.
* As a skin maintainer you can start upgrading your skin against the 
2.0.0 baseline in a separate branch. Look at the master branch of the 
maven-fluido-skin. to ease your work.


Found problems, issues or have questions? Please report via users@ or 
dev@ mailing list (whichever makes most sense) and prepend "[DOXIA]" to 
the subject. I will try to respond timely.


Expectations:
* If you intend to mix and match components and plugins between both 
major versions (Doxia 1.x vs. Doxia 2.x) you must use the highest 
maven-site-plugin version, but don't expect everything to go smoothly.
* Not every issue or behavioral change is a regression. Some changes are 
deliberate. If they are not listed in the Confluence Wiki page, let me 
know, I will add them. But in any case, feel free to reach out.


Timeline:
* By mid of July I will give the the public (users and maintainers) at 
least 30 days (but no later than 2024-08-15) to review the changes in 
the stack, the 'doxia-2.0.0' branches, evaluate your plugin upgrade path 
and/or release new versions of plugins with old stack.
* By mid of August I will start merging the 'doxia-2.0.0' branches into 
every of our reporting plugins and perform the release procedure.
* After the reporting plugins from us (Maven Core Team) have been 
released I will again give the public at least 30 days (but no later 
than 2024-10-15) to review the upgraded and released plugins.
* If no issues are reported against components or plugins until mid of 
October I will move all Doxia stack milestone components to a GA version 
and release the reporting plugins with those GA versions.
* At least six or twelve months after that we might remove deprecated 
code from the Doxia 2.0.0 stack likely breaking code which worked 
transitionally.


Versioning:
Components have been bumped to new major versions. Plugin versions will 
remain on 3.x due to Maven 3 compatiblity. Their minor versions will be 
bumped. Maven Site Plugin 4 will be retained for future Maven 4, a new 
branch for Maven Site Plugin 3.x (likely 3.20.0) will be created and all 
changed will be merged into that branch. The current 3.x branch will be 
renamed to 3.12.x.


I hope to complete the GA release train by end of 2024 -- after more 
than three years!


Good luck,

Michael

[ANN] Maven Resolver 2.0.0 released

[Tamás Cservenák]

The Apache Maven team is pleased to announce the release of the
Maven Resolver 2.0.0:

The 1.x resolver lineage is in "bugfix only" maintenance mode.
Maven Resolver 1.x is used in Maven 3.x, while Resolver 2.x is used in
Maven 4.x.
New stable version is Resolver 2.0.0 and will be used in upcoming Maven 4.

===

Site:
https://maven.apache.org/resolver

(note: site https://maven.apache.org/resolver-archives/resolver-1.9.21 is
used by latest Maven 3.x version, Resolver 2.0.0 is used by upcoming Maven
4.x)

Release Notes - Maven Resolver - Version 2.0.0

** Bug
* [MRESOLVER-164] - DefaultDependencyCollector filterVersions seems
always return full version range
* [MRESOLVER-334] - Maven Resolver's GenericVersionScheme diverges from
the spec
* [MRESOLVER-336] - Unexpected handling of qualifiers in
GenericVersionScheme
* [MRESOLVER-372] - Sporadic AccessDeniedEx on Windows
* [MRESOLVER-392] - Resolver installer should not be "smart" about
installs
* [MRESOLVER-413] - BF collector causes failure when
-Dmaven.artifact.threads=1 used
* [MRESOLVER-414] - MRESOLVER-377 makes several metadata related Maven
IT fail
* [MRESOLVER-436] - The Upgrading Resolver page uses classnames before
rename
* [MRESOLVER-438] - The new jdk transport bug on Java 11 and Java 17
* [MRESOLVER-441] - Undo FileUtils changes that altered non-Windows
execution path
* [MRESOLVER-455] - JDK transport: Improper handling of ofInputStream
body handlers in case of error
* [MRESOLVER-464] - JDK transport bug
* [MRESOLVER-483] - PreorderNodeListGenerator bug: may print trailing
":"
* [MRESOLVER-515] - Restore compatibility broken by MRESOLVER-496
* [MRESOLVER-521] - File locking threads not entering critical region
were "oversleeping"
* [MRESOLVER-547] - BF collector always copies artifacts, even when it
should not
* [MRESOLVER-572] - Resolver-Supplier unusable in OSGi runtimes
* [MRESOLVER-574] - Invalid Cookie set under proxy conditions



** New Feature
* [MRESOLVER-217] - Allow extra "sources" for Artifact decoration
* [MRESOLVER-301] - Artifact Generators
* [MRESOLVER-415] - New transport: JDK11 HTTP/2 capable
* [MRESOLVER-416] - New transport: Jetty, HTTP/2 capable
* [MRESOLVER-446] - Version Scheme Provider
* [MRESOLVER-451] - Expose version range processing strategies
* [MRESOLVER-512] - Scope Manager
* [MRESOLVER-518] - Improvements for version selector
* [MRESOLVER-571] - Import o.e.aether packages with the exact same
version in OSGi metadata
** Improvement
* [MRESOLVER-264] - Make file-lock the default locking
* [MRESOLVER-302] - Introduce onSession close
* [MRESOLVER-321] - Resolver while collecting may end up in busy loop
without any possibility to be stopped
* [MRESOLVER-335] - Better resolver errors for Artifact Not Found
* [MRESOLVER-377] - Introduce metadata update policy
* [MRESOLVER-384] - Support HTTP/2 in maven-resolver-transport-http
* [MRESOLVER-390] - Customize graph visiting strategy
* [MRESOLVER-420] - Prioritized components should be cached per session
* [MRESOLVER-421] - Extend NamedLock API to carry more than one name
* [MRESOLVER-445] - Simplify session handling, move out logic from
session builder
* [MRESOLVER-447] - Expose flatten method on RepositorySystem
* [MRESOLVER-450] - Add a RepositoryCache#computeIfAbsent method
* [MRESOLVER-460] - More filter improvements for H/L
* [MRESOLVER-463] - Ensure checksum record file (summary fie) is sorted
by artifact relative path and not checksum
* [MRESOLVER-465] - Make room for new version scheme implementations
* [MRESOLVER-467] - Pull out shared HTTP (Remote Included checksum) code
* [MRESOLVER-468] - Stabilize supplier binary and source compatibility
* [MRESOLVER-484] - The dependencies properties should be provided by
the resolver consumer
* [MRESOLVER-493] - Support premanaged of optional, exclusions and
properties by DependencyGraphDumper
* [MRESOLVER-494] - LOCAL_PATH Artifact property really belongs to
"system" scope (or is at least very related to it)
* [MRESOLVER-519] - Drop copies of same method, re-add them to parent
(collectors)
* [MRESOLVER-520] - Move repeated code (decorators, generators) into
Utils
* [MRESOLVER-535] - DependencyGraphDumper should be configurable
* [MRESOLVER-536] - Skip setting last modified time when FS does not
support it
* [MRESOLVER-538] - In dirty tree, nodes coming from range (and parents
having ranges) should be detectable
* [MRESOLVER-540] - TransferResource can and should tell more about
transfer
* [MRESOLVER-542] - Reduce usage of final classes
* [MRESOLVER-554] - Support configuration of upload/download threads
individually
* [MRESOLVER-570] - Remove excessive strictness of OSGi dependency
metadata
* [MRESOLVER-573] - CollectionConfiguration should ignore
module-info.java
** Wish
* [MRESOLVER-324] - Make 

[ANN] Maven Resolver 1.9.21 released

[Tamás Cservenák]

The Apache Maven team is pleased to announce the release of the
Maven Resolver 1.9.21:

The 1.x resolver lineage is in "bugfix only" maintenance mode.
Maven Resolver 1.x is used in Maven 3.x, while Resolver 2.x is used in
Maven 4.x.
New stable version is Resolver 2.0.0 and will be used in upcoming Maven 4.

===

Site:
https://maven.apache.org/resolver-archives/resolver-1.9.21/

(note: site https://maven.apache.org/resolver is used by latest stable
versions, that is of now 2.0.0)

Release Notes - Maven Resolver - Version 1.9.21

** Bug
* [MRESOLVER-572] - Resolver-Supplier unusable in OSGi runtimes
* [MRESOLVER-574] - Invalid Cookie set under proxy conditions
** New Feature
* [MRESOLVER-571] - Import o.e.aether packages with the exact same
version in OSGi metadata
** Improvement
* [MRESOLVER-570] - Remove excessive strictness of OSGi dependency
metadata
** Task
* [MRESOLVER-576] - Allow co-release of Resolver 1.x and 2.x
** Dependency upgrade
* [MRESOLVER-575] - Bump org.redisson:redisson to 3.32.0
* [MRESOLVER-577] - Bump maven version to 3.9.8

Have fun,
-The Apache Maven team

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Karl Heinz Marbaise]

On 26.06.24 21:26, Robert Turner wrote:

On Wed, Jun 26, 2024 at 5:12 AM Karl Heinz Marbaise
 wrote:


Hi,

On 26.06.24 03:51, Robert Turner wrote:

On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
 wrote:


Hi,

I'm not sure if I understand your problem correct, because based on the
copy-dependencies goal as stated in the docs:

"Goal that copies the project dependencies from the repository to a
defined location."

it copies as stated...

The question is what you expect to be copied and furthermore the the
more important question: Why do you need to copy those parts?



Sorry if it wasn't very clear -- I have done a bit of digging into it

just

now, and hopefully this additional information will help to explain what
I'm seeing (and I think it makes sense now, but still has an
undesirable result). (see below)


It was not the question of digging into that... The question was: Why do
need to use copy-dependencies in your build?



Ah, sorry I misunderstood.

That is a very relevant question, and for the most part, we do not need the
dependencies with our packages, except for one or two, where they become an
output artifact for executing from the command line (and the dependencies
either need to be in the JAR or accessible to the environment executing it.



In such case I would suggest, either to use maven-shade-plugin to create
an executable jar or maven-assembly-plugin instead of coping deps into a
lib directory...

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Project Info Reports Plugin 3.6.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Project Info Reports Plugin version 3.6.1.


https://maven.apache.org/plugins/maven-project-info-reports-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-project-info-reports-plugin
  3.6.1



Release Notes - Maven Project Info Reports Plugin - Version 3.6.1

** Bug
* [MPIR-462] - [REGRESSION] NFEx: For input string: "1.8" in 
project w/ MR dependency


** Task
* [MPIR-463] - Remove workaround to count the number of root 
content entries in JAR files


** Dependency upgrade
* [MPIR-464] - Upgrade to Maven Shared JAR 3.1.1


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

On Wed, Jun 26, 2024 at 6:04 AM Tamás Cservenák  wrote:

> Howdy,
>
> So here is how one can figure this out: using the "reverse tree" feature.
>
> Modified your reproducer command like this:
>
> $ $ rm -rf maven-cache &&
> MAVEN_ARGS="-Dmaven.repo.local.recordReverseTree=true
> -Dmaven.repo.local=./maven-cache" mvn -V package
>
> after invocation take a peek at recorded tracking data:
> $ cat
>
> maven-cache/log4j/log4j/1.2.12/.tracking/org.apache.maven.plugins_maven-dependency-plugin_jar_3.7.1.dep
> log4j:log4j:pom:1.2.12
>   log4j:log4j:jar:1.2.12 (compile) (plugin)
> commons-logging:commons-logging:jar:1.1 (compile) (plugin)
>   commons-digester:commons-digester:jar:1.8 (compile) (plugin)
> org.apache.velocity:velocity-tools:jar:2.0 (compile) (plugin)
>   org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1 (compile)
> (plugin)
> org.apache.maven.reporting:maven-reporting-impl:jar:3.2.0
> (compile) (plugin)
>   org.apache.maven.plugins:maven-dependency-plugin:jar:3.7.1 ()
> (plugin)
>
> Repository: central (https://repo.maven.apache.org/maven2/, default,
> releases)
>
> So, this node was _collected_ due commons-logging 1.1, and POM
> commons-logging 1.1 really states dep on log4j 1.2.12:
>
> https://repo.maven.apache.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom
>
> But, as Karl said, your local repository contains POM only, not the JAR,
> and this JAR was _not resolved_ (as its parent is "loser", was
> eliminated as commons-logging 1.2 prevailed):
> https://gist.github.com/cstamas/2843a4dacee418026f7f18206eabd315
>
> The POM is downloaded to build a "dirty graph" of the dependency tree, and
> in the next step is being _eliminated_ due reason noted in the tree, in
> this case "(conflicts with 1.2)".
> See
>
> https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/common-misconceptions.html
>
> So the POM is downloaded in the "collect" step, but is eliminated in the
> "transform" step, and log4j (nor commons-logging 1.1) is never "resolved"
> (JAR downloaded) that would be last step.
>
> Thanks
> T
>

Thanks for the detailed explanation -- it is much appreciated. (as well as
the suggestion to bump up the logging on Maven to find the details on what
is being fetched).



>
> On Wed, Jun 26, 2024 at 11:11 AM Karl Heinz Marbaise
>  wrote:
>
> > Hi,
> >
> > On 26.06.24 03:51, Robert Turner wrote:
> > > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
> > >  wrote:
> > >
> > >> Hi,
> > >>
> > >> I'm not sure if I understand your problem correct, because based on
> the
> > >> copy-dependencies goal as stated in the docs:
> > >>
> > >> "Goal that copies the project dependencies from the repository to a
> > >> defined location."
> > >>
> > >> it copies as stated...
> > >>
> > >> The question is what you expect to be copied and furthermore the the
> > >> more important question: Why do you need to copy those parts?
> > >>
> > >>
> > > Sorry if it wasn't very clear -- I have done a bit of digging into it
> > just
> > > now, and hopefully this additional information will help to explain
> what
> > > I'm seeing (and I think it makes sense now, but still has an
> > > undesirable result). (see below)
> >
> > It was not the question of digging into that... The question was: Why do
> > need to use copy-dependencies in your build?
> >
> >
> > >
> > >
> > >
> > >> It would also very helpful to have a full pom file of that project or
> > >> maybe a link to a github project (or alike)?
> > >>
> > >
> > >
> > > I think what is happening is that `maven-dependency-plugin` (3.7.1)
> > depends
> > > transitively on log4j 1.2.12 -- I'm still working through trying to
> > figure
> > > that out though.
> > > Originally (a few months ago), I worked around it a while back by
> simply
> > > disabling the copying of the dependencies to the target file (as
> visible
> > by
> > > the "comments" in the pom.xml [1] file), but that wasn't really ideal.
> > >
> > >
> > > To reproduce, I created a trivial pom.xml [1], and used a clean local
> > > repository for Maven, executing Maven as follows:
> > >
> > >  rm -rf maven-cache &&
> MAVEN_OPTS="-Dmaven.repo.local=./maven-cache"
> > mvn
> > > package
> > >
> > > This "builds" the trivial empty JAR file, and copies no dependencies
> (as
> > > none are declared).
> > >
> > >
> > > However, my local Maven repository (cache) now contains a really old
> > > version of log4j:
> > >
> > >  $ ls maven-cache/log4j/log4j/1.2.12/
> > >  _remote.repositories   log4j-1.2.12.pom
>  log4j-1.2.12.pom.sha1
> >
> > first that's not quite correct, because you have only the "pom" file not
> > the jar here...
> >
> > Furthermore having a pom file on your hard disk does not mean any code
> > is being executed... furthermore the log4shell part was to have service
> > started which accepts things etc...
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > >
> > > Reviewing the downloading order from the central 

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

On Wed, Jun 26, 2024 at 5:12 AM Karl Heinz Marbaise
 wrote:

> Hi,
>
> On 26.06.24 03:51, Robert Turner wrote:
> > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
> >  wrote:
> >
> >> Hi,
> >>
> >> I'm not sure if I understand your problem correct, because based on the
> >> copy-dependencies goal as stated in the docs:
> >>
> >> "Goal that copies the project dependencies from the repository to a
> >> defined location."
> >>
> >> it copies as stated...
> >>
> >> The question is what you expect to be copied and furthermore the the
> >> more important question: Why do you need to copy those parts?
> >>
> >>
> > Sorry if it wasn't very clear -- I have done a bit of digging into it
> just
> > now, and hopefully this additional information will help to explain what
> > I'm seeing (and I think it makes sense now, but still has an
> > undesirable result). (see below)
>
> It was not the question of digging into that... The question was: Why do
> need to use copy-dependencies in your build?


Ah, sorry I misunderstood.

That is a very relevant question, and for the most part, we do not need the
dependencies with our packages, except for one or two, where they become an
output artifact for executing from the command line (and the dependencies
either need to be in the JAR or accessible to the environment executing it.



> >
> >
> >
> >> It would also very helpful to have a full pom file of that project or
> >> maybe a link to a github project (or alike)?
> >>
> >
> >
> > I think what is happening is that `maven-dependency-plugin` (3.7.1)
> depends
> > transitively on log4j 1.2.12 -- I'm still working through trying to
> figure
> > that out though.
> > Originally (a few months ago), I worked around it a while back by simply
> > disabling the copying of the dependencies to the target file (as visible
> by
> > the "comments" in the pom.xml [1] file), but that wasn't really ideal.
> >
> >
> > To reproduce, I created a trivial pom.xml [1], and used a clean local
> > repository for Maven, executing Maven as follows:
> >
> >  rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache"
> mvn
> > package
> >
> > This "builds" the trivial empty JAR file, and copies no dependencies (as
> > none are declared).
> >
> >
> > However, my local Maven repository (cache) now contains a really old
> > version of log4j:
> >
> >  $ ls maven-cache/log4j/log4j/1.2.12/
> >  _remote.repositories   log4j-1.2.12.pom   log4j-1.2.12.pom.sha1
>
> first that's not quite correct, because you have only the "pom" file not
> the jar here...
>

Doh -- not sure how I missed that, but you are of course correct.

I'm trying to figure out why I have it on the build node now -- maybe I've
been chasing a red herring, or maybe I was building the "site" goal or
something -- I will narrow this down.

But without the JAR, the scanner shouldn't be finding it -- however, I do
see the JAR file on the build node, so now I need to track down which job,
and when / how it got there.


>
> Furthermore having a pom file on your hard disk does not mean any code
> is being executed... furthermore the log4shell part was to have service
> started which accepts things etc...
>

Yep, I totally agree -- I don't think it's running, so I don't think it's a
risk  --- just annoying to have to get exclusions approved, etc.


>
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > Reviewing the downloading order from the central repository, log4j-1.2.12
> > seems to come after commons-logging-1.1, and as part of the
> > `dependency:3.7.1:copy-dependencies` goal. [3]
> >
> >
> >
> >>
> >> Another point is: do you use the most recent version of all plugins in
> >> your build ?
> >>
> >
> > In the sample pom.xml, I am using the latest `maven-dependency-plugin`
> > (3.7.1) -- in this specific sample, I didn't override all the system
> > plug-ins with the latest version to keep the sample file smaller.
> However,
> > we generally keep our plug-ins up-to-date every few months.
> >
> > ..snipped original posting...
> >
> >
> >
> > The "problem" is not that the old log4j gets copied to the output folder,
> > it's that it is fetched into the local Maven cache / repository, which is
> > then picked up by security tooling (which of course complains that it is
> > ancient and has vulnerabilities).
>
> Yes, but as I mentioned before there are "only" pom file not the jar
> itself...
>
> >
> > Looking at the dependencies for `maven-dependency-plugin` on
> >
> https://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html
> > doesn't show log4j in the list -- so I'm a bit confused as to why the
> > package would be fetched to execute the goal.
> >
> > I'm sure I'm missing something obvious, so hopefully someone can clarify
> > what's going on.
> >
> > Thanks,
> >
> > Robert
> >
> >
> >
> > --- [x] referenced data ---
> >
> > [1] pom.xml
> >
> > http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> > http://www.w3.org/2001/XMLSchema-instance;
> >   

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

On Wed, Jun 26, 2024 at 1:36 AM Nils Breunese  wrote:

> Robert Turner  wrote:
>
> > The "problem" is not that the old log4j gets copied to the output folder,
> > it's that it is fetched into the local Maven cache / repository, which is
> > then picked up by security tooling (which of course complains that it is
> > ancient and has vulnerabilities).
>
> There is no guarantee that the artifacts in the local Maven repository are
> actually executed or part of the result of your build. I don’t know if it’s
> an option to change the scanning strategy in your situation, but I would
> suggest executing builds in a CI environment that doesn’t provide access to
> the public internet (use a repository manager like Artifactory or Nexus and
> have it proxy any public repositories you need, like Maven Central),
> optionally scanning build artifacts before they get deployed, and
> definitely scanning deployed artifacts periodically, because
> vulnerabilities can get discovered after deployment time. I wouldn’t then
> worry about the contents of the local Maven repository after a build so
> much anymore.
>
> Nils.
>
> Yeah, those are options of course -- I was hoping to avoid making lots of
changes to the environment if possible (lots of work of course). Thanks for
the suggestions.

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Tamás Cservenák]

Howdy,

So here is how one can figure this out: using the "reverse tree" feature.

Modified your reproducer command like this:

$ $ rm -rf maven-cache &&
MAVEN_ARGS="-Dmaven.repo.local.recordReverseTree=true
-Dmaven.repo.local=./maven-cache" mvn -V package

after invocation take a peek at recorded tracking data:
$ cat
maven-cache/log4j/log4j/1.2.12/.tracking/org.apache.maven.plugins_maven-dependency-plugin_jar_3.7.1.dep
log4j:log4j:pom:1.2.12
  log4j:log4j:jar:1.2.12 (compile) (plugin)
commons-logging:commons-logging:jar:1.1 (compile) (plugin)
  commons-digester:commons-digester:jar:1.8 (compile) (plugin)
org.apache.velocity:velocity-tools:jar:2.0 (compile) (plugin)
  org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1 (compile)
(plugin)
org.apache.maven.reporting:maven-reporting-impl:jar:3.2.0
(compile) (plugin)
  org.apache.maven.plugins:maven-dependency-plugin:jar:3.7.1 ()
(plugin)

Repository: central (https://repo.maven.apache.org/maven2/, default,
releases)

So, this node was _collected_ due commons-logging 1.1, and POM
commons-logging 1.1 really states dep on log4j 1.2.12:
https://repo.maven.apache.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom

But, as Karl said, your local repository contains POM only, not the JAR,
and this JAR was _not resolved_ (as its parent is "loser", was
eliminated as commons-logging 1.2 prevailed):
https://gist.github.com/cstamas/2843a4dacee418026f7f18206eabd315

The POM is downloaded to build a "dirty graph" of the dependency tree, and
in the next step is being _eliminated_ due reason noted in the tree, in
this case "(conflicts with 1.2)".
See
https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/common-misconceptions.html

So the POM is downloaded in the "collect" step, but is eliminated in the
"transform" step, and log4j (nor commons-logging 1.1) is never "resolved"
(JAR downloaded) that would be last step.

Thanks
T

On Wed, Jun 26, 2024 at 11:11 AM Karl Heinz Marbaise
 wrote:

> Hi,
>
> On 26.06.24 03:51, Robert Turner wrote:
> > On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
> >  wrote:
> >
> >> Hi,
> >>
> >> I'm not sure if I understand your problem correct, because based on the
> >> copy-dependencies goal as stated in the docs:
> >>
> >> "Goal that copies the project dependencies from the repository to a
> >> defined location."
> >>
> >> it copies as stated...
> >>
> >> The question is what you expect to be copied and furthermore the the
> >> more important question: Why do you need to copy those parts?
> >>
> >>
> > Sorry if it wasn't very clear -- I have done a bit of digging into it
> just
> > now, and hopefully this additional information will help to explain what
> > I'm seeing (and I think it makes sense now, but still has an
> > undesirable result). (see below)
>
> It was not the question of digging into that... The question was: Why do
> need to use copy-dependencies in your build?
>
>
> >
> >
> >
> >> It would also very helpful to have a full pom file of that project or
> >> maybe a link to a github project (or alike)?
> >>
> >
> >
> > I think what is happening is that `maven-dependency-plugin` (3.7.1)
> depends
> > transitively on log4j 1.2.12 -- I'm still working through trying to
> figure
> > that out though.
> > Originally (a few months ago), I worked around it a while back by simply
> > disabling the copying of the dependencies to the target file (as visible
> by
> > the "comments" in the pom.xml [1] file), but that wasn't really ideal.
> >
> >
> > To reproduce, I created a trivial pom.xml [1], and used a clean local
> > repository for Maven, executing Maven as follows:
> >
> >  rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache"
> mvn
> > package
> >
> > This "builds" the trivial empty JAR file, and copies no dependencies (as
> > none are declared).
> >
> >
> > However, my local Maven repository (cache) now contains a really old
> > version of log4j:
> >
> >  $ ls maven-cache/log4j/log4j/1.2.12/
> >  _remote.repositories   log4j-1.2.12.pom   log4j-1.2.12.pom.sha1
>
> first that's not quite correct, because you have only the "pom" file not
> the jar here...
>
> Furthermore having a pom file on your hard disk does not mean any code
> is being executed... furthermore the log4shell part was to have service
> started which accepts things etc...
>
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > Reviewing the downloading order from the central repository, log4j-1.2.12
> > seems to come after commons-logging-1.1, and as part of the
> > `dependency:3.7.1:copy-dependencies` goal. [3]
> >
> >
> >
> >>
> >> Another point is: do you use the most recent version of all plugins in
> >> your build ?
> >>
> >
> > In the sample pom.xml, I am using the latest `maven-dependency-plugin`
> > (3.7.1) -- in this specific sample, I didn't override all the system
> > plug-ins with the latest version to keep the sample file smaller.
> However,
> > we 

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Karl Heinz Marbaise]

Hi,

On 26.06.24 03:51, Robert Turner wrote:

On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
 wrote:


Hi,

I'm not sure if I understand your problem correct, because based on the
copy-dependencies goal as stated in the docs:

"Goal that copies the project dependencies from the repository to a
defined location."

it copies as stated...

The question is what you expect to be copied and furthermore the the
more important question: Why do you need to copy those parts?



Sorry if it wasn't very clear -- I have done a bit of digging into it just
now, and hopefully this additional information will help to explain what
I'm seeing (and I think it makes sense now, but still has an
undesirable result). (see below)


It was not the question of digging into that... The question was: Why do
need to use copy-dependencies in your build?







It would also very helpful to have a full pom file of that project or
maybe a link to a github project (or alike)?




I think what is happening is that `maven-dependency-plugin` (3.7.1) depends
transitively on log4j 1.2.12 -- I'm still working through trying to figure
that out though.
Originally (a few months ago), I worked around it a while back by simply
disabling the copying of the dependencies to the target file (as visible by
the "comments" in the pom.xml [1] file), but that wasn't really ideal.


To reproduce, I created a trivial pom.xml [1], and used a clean local
repository for Maven, executing Maven as follows:

 rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache" mvn
package

This "builds" the trivial empty JAR file, and copies no dependencies (as
none are declared).


However, my local Maven repository (cache) now contains a really old
version of log4j:

 $ ls maven-cache/log4j/log4j/1.2.12/
 _remote.repositories   log4j-1.2.12.pom   log4j-1.2.12.pom.sha1


first that's not quite correct, because you have only the "pom" file not
the jar here...

Furthermore having a pom file on your hard disk does not mean any code
is being executed... furthermore the log4shell part was to have service
started which accepts things etc...


Kind regards
Karl Heinz Marbaise



Reviewing the downloading order from the central repository, log4j-1.2.12
seems to come after commons-logging-1.1, and as part of the
`dependency:3.7.1:copy-dependencies` goal. [3]





Another point is: do you use the most recent version of all plugins in
your build ?



In the sample pom.xml, I am using the latest `maven-dependency-plugin`
(3.7.1) -- in this specific sample, I didn't override all the system
plug-ins with the latest version to keep the sample file smaller. However,
we generally keep our plug-ins up-to-date every few months.

..snipped original posting...



The "problem" is not that the old log4j gets copied to the output folder,
it's that it is fetched into the local Maven cache / repository, which is
then picked up by security tooling (which of course complains that it is
ancient and has vulnerabilities).


Yes, but as I mentioned before there are "only" pom file not the jar
itself...



Looking at the dependencies for `maven-dependency-plugin` on
https://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html
doesn't show log4j in the list -- so I'm a bit confused as to why the
package would be fetched to execute the goal.

I'm sure I'm missing something obvious, so hopefully someone can clarify
what's going on.

Thanks,

Robert



--- [x] referenced data ---

[1] pom.xml

http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
 4.0.0
 org.fake
 dependency-fetching-issue
 jar
 dependency-fetching-issue
 1.${revision}
 Dependency Fetching Issue

 
 
 
 maven-dependency-plugin
 3.7.1

 
 
 package
 
 copy-dependencies
 
 

${project.build.directory}/lib
 
 
 

  
 
 

 
 
 
 
 0-SNAPSHOT
 UTF-8
 



[2] mvn --version output

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec
Java version: 17.0.11, vendor: Amazon.com Inc., runtime:
/Library/Java/JavaVirtualMachines/amazon-corretto-17.jdk/Contents/Home
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac"


[3]  downloading output for dependency:3.7.1:copy-dependencies goal

[INFO] --- dependency:3.7.1:copy-dependencies (default) @
dependency-fetching-issue ---
Downloading from central:

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Nils Breunese]

Robert Turner  wrote:

> The "problem" is not that the old log4j gets copied to the output folder,
> it's that it is fetched into the local Maven cache / repository, which is
> then picked up by security tooling (which of course complains that it is
> ancient and has vulnerabilities).

There is no guarantee that the artifacts in the local Maven repository are 
actually executed or part of the result of your build. I don’t know if it’s an 
option to change the scanning strategy in your situation, but I would suggest 
executing builds in a CI environment that doesn’t provide access to the public 
internet (use a repository manager like Artifactory or Nexus and have it proxy 
any public repositories you need, like Maven Central), optionally scanning 
build artifacts before they get deployed, and definitely scanning deployed 
artifacts periodically, because vulnerabilities can get discovered after 
deployment time. I wouldn’t then worry about the contents of the local Maven 
repository after a build so much anymore.

Nils.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

On Tue, Jun 25, 2024 at 9:51 PM Robert Turner  wrote:

>
> On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
>  wrote:
>
>> Hi,
>>
>> I'm not sure if I understand your problem correct, because based on the
>> copy-dependencies goal as stated in the docs:
>>
>> "Goal that copies the project dependencies from the repository to a
>> defined location."
>>
>> it copies as stated...
>>
>> The question is what you expect to be copied and furthermore the the
>> more important question: Why do you need to copy those parts?
>>
>>
> Sorry if it wasn't very clear -- I have done a bit of digging into it just
> now, and hopefully this additional information will help to explain what
> I'm seeing (and I think it makes sense now, but still has an
> undesirable result). (see below)
>
>
>
>> It would also very helpful to have a full pom file of that project or
>> maybe a link to a github project (or alike)?
>>
>
>
> I think what is happening is that `maven-dependency-plugin` (3.7.1)
> depends transitively on log4j 1.2.12 -- I'm still working through trying to
> figure that out though.
>

I think the dependency tree is as follows (running `mvn dependencies:tree`
on the `maven-dependency-plugin` code results in the following):

org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:3.7.1
org.apache.maven.reporting:maven-reporting-impl:jar:3.2.0
org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1
org.apache.velocity:velocity-tools:jar:2.0
commons-logging:commons-logging:jar:1.1
 ... the tree stops here, butcommons-logging:1.1 shows log4j 1.2.12 as
a compile dependency (
https://mvnrepository.com/artifact/commons-logging/commons-logging/1.1)

But (as of yet) I don't know why it would get pulled in as a runtime
dependency



> Originally (a few months ago), I worked around it a while back by simply
> disabling the copying of the dependencies to the target file (as visible by
> the "comments" in the pom.xml [1] file), but that wasn't really ideal.
>
>
> To reproduce, I created a trivial pom.xml [1], and used a clean local
> repository for Maven, executing Maven as follows:
>
> rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache"
> mvn package
>
> This "builds" the trivial empty JAR file, and copies no dependencies (as
> none are declared).
>
>
> However, my local Maven repository (cache) now contains a really old
> version of log4j:
>
> $ ls maven-cache/log4j/log4j/1.2.12/
> _remote.repositories   log4j-1.2.12.pom   log4j-1.2.12.pom.sha1
>
> Reviewing the downloading order from the central repository, log4j-1.2.12
> seems to come after commons-logging-1.1, and as part of the
> `dependency:3.7.1:copy-dependencies` goal. [3]
>
>
>
>>
>> Another point is: do you use the most recent version of all plugins in
>> your build ?
>>
>
> In the sample pom.xml, I am using the latest `maven-dependency-plugin`
> (3.7.1) -- in this specific sample, I didn't override all the system
> plug-ins with the latest version to keep the sample file smaller. However,
> we generally keep our plug-ins up-to-date every few months.
>
> ..snipped original posting...
>
>
>
> The "problem" is not that the old log4j gets copied to the output folder,
> it's that it is fetched into the local Maven cache / repository, which is
> then picked up by security tooling (which of course complains that it is
> ancient and has vulnerabilities).
>
> Looking at the dependencies for `maven-dependency-plugin` on
> https://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html
> doesn't show log4j in the list -- so I'm a bit confused as to why the
> package would be fetched to execute the goal.
>
> I'm sure I'm missing something obvious, so hopefully someone can clarify
> what's going on.
>
> Thanks,
>
> Robert
>
>
>
> --- [x] referenced data ---
>
> [1] pom.xml
>
> http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
> org.fake
> dependency-fetching-issue
> jar
> dependency-fetching-issue
> 1.${revision}
> Dependency Fetching Issue
>
> 
> 
> 
> maven-dependency-plugin
> 3.7.1
> 
> 
> 
> package
> 
> copy-dependencies
> 
> 
>
> ${project.build.directory}/lib
> 
> 
> 
> 
>  
> 
> 
>
> 
> 
> 
> 
> 0-SNAPSHOT
> UTF-8
> 
> 
>
>
> [2] mvn --version output
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec
> Java version: 17.0.11, vendor: Amazon.com Inc., runtime:
> /Library/Java/JavaVirtualMachines/amazon-corretto-17.jdk/Contents/Home
> 

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

On Tue, Jun 25, 2024 at 8:36 PM Karl Heinz Marbaise
 wrote:

> Hi,
>
> I'm not sure if I understand your problem correct, because based on the
> copy-dependencies goal as stated in the docs:
>
> "Goal that copies the project dependencies from the repository to a
> defined location."
>
> it copies as stated...
>
> The question is what you expect to be copied and furthermore the the
> more important question: Why do you need to copy those parts?
>
>
Sorry if it wasn't very clear -- I have done a bit of digging into it just
now, and hopefully this additional information will help to explain what
I'm seeing (and I think it makes sense now, but still has an
undesirable result). (see below)



> It would also very helpful to have a full pom file of that project or
> maybe a link to a github project (or alike)?
>


I think what is happening is that `maven-dependency-plugin` (3.7.1) depends
transitively on log4j 1.2.12 -- I'm still working through trying to figure
that out though.
Originally (a few months ago), I worked around it a while back by simply
disabling the copying of the dependencies to the target file (as visible by
the "comments" in the pom.xml [1] file), but that wasn't really ideal.


To reproduce, I created a trivial pom.xml [1], and used a clean local
repository for Maven, executing Maven as follows:

rm -rf maven-cache && MAVEN_OPTS="-Dmaven.repo.local=./maven-cache" mvn
package

This "builds" the trivial empty JAR file, and copies no dependencies (as
none are declared).


However, my local Maven repository (cache) now contains a really old
version of log4j:

$ ls maven-cache/log4j/log4j/1.2.12/
_remote.repositories   log4j-1.2.12.pom   log4j-1.2.12.pom.sha1

Reviewing the downloading order from the central repository, log4j-1.2.12
seems to come after commons-logging-1.1, and as part of the
`dependency:3.7.1:copy-dependencies` goal. [3]



>
> Another point is: do you use the most recent version of all plugins in
> your build ?
>

In the sample pom.xml, I am using the latest `maven-dependency-plugin`
(3.7.1) -- in this specific sample, I didn't override all the system
plug-ins with the latest version to keep the sample file smaller. However,
we generally keep our plug-ins up-to-date every few months.

..snipped original posting...



The "problem" is not that the old log4j gets copied to the output folder,
it's that it is fetched into the local Maven cache / repository, which is
then picked up by security tooling (which of course complains that it is
ancient and has vulnerabilities).

Looking at the dependencies for `maven-dependency-plugin` on
https://maven.apache.org/plugins/maven-dependency-plugin/dependencies.html
doesn't show log4j in the list -- so I'm a bit confused as to why the
package would be fetched to execute the goal.

I'm sure I'm missing something obvious, so hopefully someone can clarify
what's going on.

Thanks,

Robert



--- [x] referenced data ---

[1] pom.xml

http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
org.fake
dependency-fetching-issue
jar
dependency-fetching-issue
1.${revision}
Dependency Fetching Issue




maven-dependency-plugin
3.7.1



package

copy-dependencies



${project.build.directory}/lib




 







0-SNAPSHOT
UTF-8




[2] mvn --version output

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec
Java version: 17.0.11, vendor: Amazon.com Inc., runtime:
/Library/Java/JavaVirtualMachines/amazon-corretto-17.jdk/Contents/Home
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac"


[3]  downloading output for dependency:3.7.1:copy-dependencies goal

[INFO] --- dependency:3.7.1:copy-dependencies (default) @
dependency-fetching-issue ---
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.12.0/doxia-sink-api-1.12.0.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.12.0/doxia-sink-api-1.12.0.pom
(1.5 kB at 22 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia/1.12.0/doxia-1.12.0.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia/1.12.0/doxia-1.12.0.pom
(18 kB at 248 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-logging-api/1.12.0/doxia-logging-api-1.12.0.pom

Re: maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Karl Heinz Marbaise]

Hi,

I'm not sure if I understand your problem correct, because based on the
copy-dependencies goal as stated in the docs:

"Goal that copies the project dependencies from the repository to a
defined location."

it copies as stated...

The question is what you expect to be copied and furthermore the the
more important question: Why do you need to copy those parts?

It would also very helpful to have a full pom file of that project or
maybe a link to a github project (or alike)?

Another point is: do you use the most recent version of all plugins in
your build ?


Kind regards
Karl Heinz Marbaise

On 24.06.24 17:31, Robert Turner wrote:

(Note I had originally sent this on Feb 14, but I think it never got posted
to the mailing list -- likely because I forgot to subscribe first -- as
such, some of the version information may not be "current" as of today).

All:

I'm looking into an issue where we had an old package [1] flagged by
security tooling as being present on our build servers in the Maven
repository (~/.m2/repository). After a bit of digging, I managed to narrow
down where it came from and when it got fetched, and I can reproduce in a
pretty narrow use case as well.

We have a library (jar) that gets built for the purposes of a REST API.
This package was generated with some automated tooling, but has been
hand-tweaked. However, the specifics of the package do not seem to be that
important (other than the tools it uses). The specific plugin with the
transitive dependency to the offending package [1] is
"maven-javadoc-plugin" (which likely needs some updates of dependencies,
etc, in particular maven-reporting- which seem to be the ones that are
older).

During our build process, "maven-dependency-plugin" is used with the goal
"copy-dependencies" to copy runtime artifacts to the output directory
(target/lib) [2]. It does this, and copies in about 15 or so files as
expected. [3] None of these files are the "offending" package being flagged
by the security tools.

However, if you clean your Maven repository (rm -rf ~/.m2/repository), and
run either the build up to and including the dependency copying (e.g. mvn
package) [3], or just run "mvn dependency:tree" [4], the offending package
gets copied into the local Maven repository (~/.m2/repository).


So, my questions are:

a) Why does maven-dependency-plugin fetch absolutely everything regardless
of how far it actually needs to traverse the tree to do the task it's
performing? (or does it really need to traverse the whole tree?)

b) Is there a way to stop this behaviour without either removing the
dependency (maven-javadoc.plugin) with the offending dependency [1] from
the project, or not using "maven-dependency-plugin"? I have tried some
exclusion methods documented for the goals, but they do not seem to change
the fetching / tree traversal behaviour.


Thanks,

Robert



== References / Details ==

[1] log4j:log4j:1.2.12


[2]
 
 maven-dependency-plugin
 3.6.1
 
 
 package
 
 copy-dependencies
 
 

${project.build.directory}/lib
 
 
 
 


[3]
$ rm -rf ~/.m2/repository
$ mvn package
09:26:55.703 [INFO] Scanning for projects...
09:26:55.726 [INFO]

...snip...

09:27:14.083 [INFO]
09:27:14.083 [INFO] --- dependency:3.6.1:copy-dependencies (default) @
 ---
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.pom
(1.6 kB at 27 kB/s)

...snip...

Downloading from central:
https://repo.maven.apache.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.pom
(145 B at 2.1 kB/s)

...snip...

Downloaded from central:
https://repo.maven.apache.org/maven2/com/github/luben/zstd-jni/1.5.5-5/zstd-jni-1.5.5-5.jar
(5.9 MB at 3.7 MB/s)
09:27:28.043 [INFO] com.google.code.findbugs:jsr305:jar:3.0.2 already
exists in destination.
09:27:28.043 [INFO] org.apache.httpcomponents.client5:httpclient5:jar:5.2.1
already exists in destination.
09:27:28.043 [INFO] org.apache.httpcomponents.core5:httpcore5:jar:5.2
already exists in destination.
09:27:28.043 [INFO] org.apache.httpcomponents.core5:httpcore5-h2:jar:5.2
already exists in destination.
09:27:28.043 [INFO] org.slf4j:slf4j-api:jar:1.7.36 already exists in
destination.
09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-core:jar:2.15.2
already exists in destination.
09:27:28.043 [INFO]
com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2 already exists in
destination.
09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-databind:jar:2.15.2
already 

[ANN] Apache Maven Daemon 2.0.0-beta-1 released

[Tamás Cservenák]

The Apache Maven team is pleased to announce the release of the Apache
Maven Daemon version 2.0.0-beta-1

This release provides binaries based on Maven 4.0.0-beta-3.

(From now on, Maven Daemon 1.x line will wrap Maven 3.x binaries, while
Maven Daemon 2.x will wrap Maven 4.x binaries. Previous releases used the
same version for both binaries with "m39" and "m40" designators, they are
now gone.)

The release source and binary bundles are available for download at:
https://downloads.apache.org/maven/mvnd/2.0.0-beta-1/

The changelog is available at:
https://github.com/apache/maven-mvnd/releases/tag/2.0.0-beta-1

If you have any questions, please consult:
- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues

Regards,
The Apache Maven Team

per module repository settings

[Delany]

The update policy for snapshot artifacts in my project is set to "daily"
and this applies to all modules.
I would like to apply a different policy to selected modules, since the
artifacts they produce are quite big.
Is this possible?

Its not enough to override the configuration of the selected modules.
Effective pom shows the configuration is carried, but Maven/resolver
ignores it.

  

  
true
never
  

https://maven.apache.org/ref/3.9.8/maven-model/maven.html#class_snapshots

The snapshot repository must remain enabled.

Kind regards,
Delany

Re: [ANN] Apache Maven Daemon 1.0.1 released

[Greg Chabala]

I can read the project README, yes.

Are there plans to publish anything about mvnd on the official Maven
website? Acknowledging it exists, linking to the repo, anything like that?

On Mon, Jun 24, 2024 at 1:56 PM Slawomir Jaranowski 
wrote:

> pon., 24 cze 2024 o 16:57 Greg Chabala 
> napisał(a):
>
> > >
> > > If you have any questions, please consult:
> > > - the web site: https://maven.apache.org/
> >
> >
> > Are there any pages on the website about mvnd? I don't see it mentioned
> > anywhere.
> >
>
> You can read https://github.com/apache/maven-mvnd
>
>
> >
> > On Mon, Jun 24, 2024 at 1:33 AM Slawomir Jaranowski <
> > sjaranow...@apache.org>
> > wrote:
> >
> > > The Apache Maven team is pleased to announce the release of the Apache
> > > Maven Daemon version 1.0.1
> > >
> > > This release provides binaries based on Maven 3.9.8.
> > >
> > > (From now on, Maven Daemon 1.x line will wrap Maven 3.x binaries, while
> > > Maven Daemon 2.x will wrap Maven 4.x binaries. Previous releases used
> the
> > > same version for both binaries with "m39" and "m40" designators, they
> are
> > > now gone.)
> > >
> > > The release source and binary bundles are available for download at:
> > > https://downloads.apache.org/maven/mvnd/1.0.1/
> > >
> > > The changelog is available at:
> > > https://github.com/apache/maven-mvnd/releases/tag/1.0.1
> > >
> > > If you have any questions, please consult:
> > > - the web site: https://maven.apache.org/
> > > - the maven-user mailing list:
> > https://maven.apache.org/mailing-lists.html
> > > - the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues
> > >
> > > Regards,
> > > The Apache Maven Team
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: [ANN] Apache Maven Daemon 1.0.1 released

[Slawomir Jaranowski]

pon., 24 cze 2024 o 16:57 Greg Chabala  napisał(a):

> >
> > If you have any questions, please consult:
> > - the web site: https://maven.apache.org/
>
>
> Are there any pages on the website about mvnd? I don't see it mentioned
> anywhere.
>

You can read https://github.com/apache/maven-mvnd


>
> On Mon, Jun 24, 2024 at 1:33 AM Slawomir Jaranowski <
> sjaranow...@apache.org>
> wrote:
>
> > The Apache Maven team is pleased to announce the release of the Apache
> > Maven Daemon version 1.0.1
> >
> > This release provides binaries based on Maven 3.9.8.
> >
> > (From now on, Maven Daemon 1.x line will wrap Maven 3.x binaries, while
> > Maven Daemon 2.x will wrap Maven 4.x binaries. Previous releases used the
> > same version for both binaries with "m39" and "m40" designators, they are
> > now gone.)
> >
> > The release source and binary bundles are available for download at:
> > https://downloads.apache.org/maven/mvnd/1.0.1/
> >
> > The changelog is available at:
> > https://github.com/apache/maven-mvnd/releases/tag/1.0.1
> >
> > If you have any questions, please consult:
> > - the web site: https://maven.apache.org/
> > - the maven-user mailing list:
> https://maven.apache.org/mailing-lists.html
> > - the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues
> >
> > Regards,
> > The Apache Maven Team
> >
>


-- 
Sławomir Jaranowski

maven-dependency-plugin fetches all transitive project dependencies into local Maven cache (~/.m2/repository)

[Robert Turner]

(Note I had originally sent this on Feb 14, but I think it never got posted
to the mailing list -- likely because I forgot to subscribe first -- as
such, some of the version information may not be "current" as of today).

All:

I'm looking into an issue where we had an old package [1] flagged by
security tooling as being present on our build servers in the Maven
repository (~/.m2/repository). After a bit of digging, I managed to narrow
down where it came from and when it got fetched, and I can reproduce in a
pretty narrow use case as well.

We have a library (jar) that gets built for the purposes of a REST API.
This package was generated with some automated tooling, but has been
hand-tweaked. However, the specifics of the package do not seem to be that
important (other than the tools it uses). The specific plugin with the
transitive dependency to the offending package [1] is
"maven-javadoc-plugin" (which likely needs some updates of dependencies,
etc, in particular maven-reporting- which seem to be the ones that are
older).

During our build process, "maven-dependency-plugin" is used with the goal
"copy-dependencies" to copy runtime artifacts to the output directory
(target/lib) [2]. It does this, and copies in about 15 or so files as
expected. [3] None of these files are the "offending" package being flagged
by the security tools.

However, if you clean your Maven repository (rm -rf ~/.m2/repository), and
run either the build up to and including the dependency copying (e.g. mvn
package) [3], or just run "mvn dependency:tree" [4], the offending package
gets copied into the local Maven repository (~/.m2/repository).


So, my questions are:

a) Why does maven-dependency-plugin fetch absolutely everything regardless
of how far it actually needs to traverse the tree to do the task it's
performing? (or does it really need to traverse the whole tree?)

b) Is there a way to stop this behaviour without either removing the
dependency (maven-javadoc.plugin) with the offending dependency [1] from
the project, or not using "maven-dependency-plugin"? I have tried some
exclusion methods documented for the goals, but they do not seem to change
the fetching / tree traversal behaviour.


Thanks,

Robert



== References / Details ==

[1] log4j:log4j:1.2.12


[2]

maven-dependency-plugin
3.6.1


package

copy-dependencies



${project.build.directory}/lib






[3]
$ rm -rf ~/.m2/repository
$ mvn package
09:26:55.703 [INFO] Scanning for projects...
09:26:55.726 [INFO]

...snip...

09:27:14.083 [INFO]
09:27:14.083 [INFO] --- dependency:3.6.1:copy-dependencies (default) @
 ---
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.pom
(1.6 kB at 27 kB/s)

...snip...

Downloading from central:
https://repo.maven.apache.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/log4j/log4j/1.2.12/log4j-1.2.12.pom
(145 B at 2.1 kB/s)

...snip...

Downloaded from central:
https://repo.maven.apache.org/maven2/com/github/luben/zstd-jni/1.5.5-5/zstd-jni-1.5.5-5.jar
(5.9 MB at 3.7 MB/s)
09:27:28.043 [INFO] com.google.code.findbugs:jsr305:jar:3.0.2 already
exists in destination.
09:27:28.043 [INFO] org.apache.httpcomponents.client5:httpclient5:jar:5.2.1
already exists in destination.
09:27:28.043 [INFO] org.apache.httpcomponents.core5:httpcore5:jar:5.2
already exists in destination.
09:27:28.043 [INFO] org.apache.httpcomponents.core5:httpcore5-h2:jar:5.2
already exists in destination.
09:27:28.043 [INFO] org.slf4j:slf4j-api:jar:1.7.36 already exists in
destination.
09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-core:jar:2.15.2
already exists in destination.
09:27:28.043 [INFO]
com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2 already exists in
destination.
09:27:28.043 [INFO] com.fasterxml.jackson.core:jackson-databind:jar:2.15.2
already exists in destination.
09:27:28.043 [INFO]
com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.15.2 already
exists in destination.
09:27:28.043 [INFO]
com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.15.2 already exists in
destination.
09:27:28.043 [INFO]
com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.15.2
already exists in destination.
09:27:28.043 [INFO] jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.3 already
exists in destination.
09:27:28.043 [INFO] jakarta.activation:jakarta.activation-api:jar:1.2.2
already exists in destination.
09:27:28.043 [INFO]
com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.2 

Re: [ANN] Apache Maven Daemon 1.0.1 released

[Greg Chabala]

>
> If you have any questions, please consult:
> - the web site: https://maven.apache.org/


Are there any pages on the website about mvnd? I don't see it mentioned
anywhere.

On Mon, Jun 24, 2024 at 1:33 AM Slawomir Jaranowski 
wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven Daemon version 1.0.1
>
> This release provides binaries based on Maven 3.9.8.
>
> (From now on, Maven Daemon 1.x line will wrap Maven 3.x binaries, while
> Maven Daemon 2.x will wrap Maven 4.x binaries. Previous releases used the
> same version for both binaries with "m39" and "m40" designators, they are
> now gone.)
>
> The release source and binary bundles are available for download at:
> https://downloads.apache.org/maven/mvnd/1.0.1/
>
> The changelog is available at:
> https://github.com/apache/maven-mvnd/releases/tag/1.0.1
>
> If you have any questions, please consult:
> - the web site: https://maven.apache.org/
> - the maven-user mailing list: https://maven.apache.org/mailing-lists.html
> - the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues
>
> Regards,
> The Apache Maven Team
>

[ANN] Apache Maven Daemon 1.0.1 released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Daemon version 1.0.1

This release provides binaries based on Maven 3.9.8.

(From now on, Maven Daemon 1.x line will wrap Maven 3.x binaries, while
Maven Daemon 2.x will wrap Maven 4.x binaries. Previous releases used the
same version for both binaries with "m39" and "m40" designators, they are
now gone.)

The release source and binary bundles are available for download at:
https://downloads.apache.org/maven/mvnd/1.0.1/

The changelog is available at:
https://github.com/apache/maven-mvnd/releases/tag/1.0.1

If you have any questions, please consult:
- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues

Regards,
The Apache Maven Team

[ANN] Apache Maven Shared JAR 3.1.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Apache 
Maven Shared JAR, version 3.1.1.


https://maven.apache.org/shared/maven-shared-jar/


Release Notes - Apache Maven Shared JAR - Version 3.1.1

** Bug
* [MSHARED-1411] - Allow access the root entries if it is a 
multi-release JAR file


** Task
* [MSHARED-1413] - Review Multi-Release JAR analysis support


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Dependency Plugin 3.7.1 released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Maven
Dependency Plugin version 3.7.1

https://maven.apache.org/plugins/maven-dependency-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-dependency-plugin
  3.7.1


You can download the appropriate sources etc. from the download page:
https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi

Release Notes - Maven Dependency Plugin - Version 3.7.1

** Bug
* [MDEP-943] - [REGRESSION] appendOutput for tree goal broken for
multi-module project

** Improvement
* [MDEP-940] - Use Resolver API instead of m-a-t for resolving artifacts

** Task
* [MDEP-945] - Fix documentation about get goal

** Dependency upgrade
* [MDEP-944] - Bump
org.apache.maven.shared:maven-common-artifact-filters from 3.3.2 to 3.4.0

Enjoy,

-The Apache Maven team

Re: Common Artifact Filters -> Downgrade from maven-resolver-util 1.6.3 to 1.4.1

[Slawomir Jaranowski]

pt., 21 cze 2024 o 16:39 Michael Osipov  napisał(a):

> On 2024/06/21 13:18:26 STEFFAN Alexandra wrote:
> > Hi,
> >
> > We've noticed that the Maven Common Artifact Filters has a dependency on
> maven-resolver-util. This dependency has been downgraded from 1.6.3 to
> 1.4.1 in Common Artifact Filters 3.4.0.
> >
> > This was done in commit
> https://github.com/apache/maven-common-artifact-filters/pull/36/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8L60-R60
> .
> >
> > It has come to our attention that version 1.4.1 uses a PGP Key without a
> UID and we can't verify the maintainer of this version.
> >
> > a) Was the change intentional?
>
> Yes
>
> > b) Is the PGP key verifiable with the fingerprint
> org.apache.maven.resolver:maven-resolver-api:1.4.1 =
> 0x522CA055B326A636D833EF6A0551FD3684FCBBB7?
>
>
> https://keyserver.ubuntu.com/pks/lookup?search=0x522CA055B326A636D833EF6A0551FD3684FCBBB7=on=index


also can check key in: https://downloads.apache.org/maven/KEYS


>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: Common Artifact Filters -> Downgrade from maven-resolver-util 1.6.3 to 1.4.1

[Michael Osipov]

On 2024/06/21 13:18:26 STEFFAN Alexandra wrote:
> Hi,
> 
> We've noticed that the Maven Common Artifact Filters has a dependency on 
> maven-resolver-util. This dependency has been downgraded from 1.6.3 to 1.4.1 
> in Common Artifact Filters 3.4.0.
> 
> This was done in commit 
> https://github.com/apache/maven-common-artifact-filters/pull/36/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8L60-R60
>  .
> 
> It has come to our attention that version 1.4.1 uses a PGP Key without a UID 
> and we can't verify the maintainer of this version.
> 
> a) Was the change intentional?

Yes

> b) Is the PGP key verifiable with the fingerprint 
> org.apache.maven.resolver:maven-resolver-api:1.4.1 = 
> 0x522CA055B326A636D833EF6A0551FD3684FCBBB7?

https://keyserver.ubuntu.com/pks/lookup?search=0x522CA055B326A636D833EF6A0551FD3684FCBBB7=on=index

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Common Artifact Filters -> Downgrade from maven-resolver-util 1.6.3 to 1.4.1

[STEFFAN Alexandra]

Hi,

We've noticed that the Maven Common Artifact Filters has a dependency on 
maven-resolver-util. This dependency has been downgraded from 1.6.3 to 1.4.1 in 
Common Artifact Filters 3.4.0.

This was done in commit 
https://github.com/apache/maven-common-artifact-filters/pull/36/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8L60-R60
 .

It has come to our attention that version 1.4.1 uses a PGP Key without a UID 
and we can't verify the maintainer of this version.

a) Was the change intentional?
b) Is the PGP key verifiable with the fingerprint 
org.apache.maven.resolver:maven-resolver-api:1.4.1 = 
0x522CA055B326A636D833EF6A0551FD3684FCBBB7?

Best regards

Alexandra Steffan


C1-Internal Use

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven SCM Publish Plugin 3.3.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
SCM Publish Plugin version 3.3.0.


https://maven.apache.org/plugins/maven-scm-publish-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-scm-publish-plugin
  3.3.0



Release Notes - Maven SCM Publish Plugin - Version 3.3.0

** Bug
* [MSCMPUB-69] - ITs do not properly check for existence of 
svn/svnadmin/CreateSymbolicLink command/function


** Improvement
* [MSCMPUB-61] - Leverage the distributionManagement.site.id by 
default for parameter "serverId"
* [MSCMPUB-63] - Rely on DefaultScmRepositoryConfigurator from 
maven-release for extracting credentials from settings.xml


** Dependency upgrade
* [MSCMPUB-64] - Upgrade parent POM to version 41
* [MSCMPUB-65] - Upgrade commons-io:commons-io to 2.16.0
* [MSCMPUB-66] - Upgrade org.codehaus.plexus:plexus-utils to 4.0.0
* [MSCMPUB-67] - Upgrade to Maven 3.6.3
* [MSCMPUB-68] - Upgrade plugins and components (in ITs)


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven JAR Plugin 3.4.2 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven JAR Plugin, version 3.4.2

This plugin provides the capability to build jars.

https://maven.apache.org/plugins/maven-jar-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-jar-plugin
  3.4.2


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-jar-plugin/download.cgi


Release Notes - Maven JAR Plugin - Version 3.4.2

** Bug
* [MJAR-310] - [REGRESSION] Plugin fails to handle toolchain paths that
contain spaces

Enjoy,

-The Apache Maven team

[ANN] Apache Maven Clean Plugin 3.4.0 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Clean Plugin, version 3.4.0

This plugin is used when you want to remove files generated at build-time
in a project's directory.

https://maven.apache.org/plugins/maven-clean-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-clean-plugin
  3.4.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-clean-plugin/download.cgi

Release Notes - Maven Clean Plugin - Version 3.4.0

** Improvement
* [MCLEAN-106] - Switch to Junit5
* [MCLEAN-116] - Propagating a source exception in Cleaner class
* [MCLEAN-118] - Require Maven 3.6.3

** Task
* [MCLEAN-122] - Cleanup declared dependencies, simplify unit test

** Dependency upgrade
* [MCLEAN-115] - Upgrade maven-plugin parent to 41
* [MCLEAN-119] - Upgrade Parent to 42
* [MCLEAN-120] - Bump org.codehaus.plexus:plexus-testing from 1.1.0 to
1.3.0
* [MCLEAN-121] - Bump com.google.inject:guice from 4.2.0 to 4.2.3

Enjoy,

-The Apache Maven team

[ANN] Apache Maven Daemon 1.0.0 released

[Tamás Cservenák]

The Apache Maven team is pleased to announce the release of the
Apache Maven Daemon version 1.0.0

This release provides binaries based on Maven 3.9.8.

(From now on, Maven Daemon 1.x line will wrap Maven 3.x binaries, while
Maven Daemon 2.x will wrap Maven 4.x binaries. Previous releases used the
same version for both binaries with "m39" and "m40" designators, they are
now gone.)

The release source and binary bundles are available for download at:
https://downloads.apache.org/maven/mvnd/1.0.0/

The changelog is available at:
https://github.com/apache/maven-mvnd/releases/tag/1.0.0

If you have any questions, please consult:
- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues

Regards,
The Apache Maven Team

[ANN] Apache Maven 3.9.8 released

[Tamás Cservenák]

The Apache Maven team is pleased to announce the release of the
Apache Maven 3.9.8

Apache Maven is a software project management and comprehension tool. Based
on the concept of a project object model (POM), Maven can manage a
project's build, reporting and documentation from a central piece of
information.

Maven 3.9.8 is available via https://maven.apache.org/download.cgi

The core release is independent of plugin releases. Further releases of
plugins will be made separately.

If you have any questions, please consult:

- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the reference documentation: https://maven.apache.org/ref/3.9.8/

For more information read
https://maven.apache.org/docs/3.9.8/release-notes.html

Release Notes - Maven - Version 3.9.8

** Bug
* [MNG-7758] - o.e.aether.resolution.ArtifactResolutionException
incorrectly examined when multiple repositories are involved
* [MNG-8066] - Maven hangs on self-referencing exceptions
* [MNG-8116] - Plugin configuration can randomly fail in case of method
overloading as it doesn't take into account implementation attribute
* [MNG-8131] - Property replacement in dependency pom no longer works
* [MNG-8135] - Profile activation based on OS properties is no longer
case insensitive
* [MNG-8142] - If JDK profile activator gets "invalid" JDK version for
whatever reason, it chokes but does not tell why
* [MNG-8147] - Profile interpolation broke their evaluation in case of
duplicate IDs
** Improvement
* [MNG-7902] - Sort plugins in validation report
* [MNG-8140] - When a model is discarded (by model builder) for
whatever reason, show why it happened
* [MNG-8141] - Model Builder should report if not sure about "fully
correct" outcome
* [MNG-8150] - Make SimplexTransferListener handle absent source/target
files
** Task
* [MNG-8146] - Drop use of commons-lang
** Dependency upgrade
* [MNG-8136] - Update to Eclipse Sisu 0.9.0.M3
* [MNG-8143] - Update to commons-cli 1.8.0
* [MNG-8144] - Update to Guava 32.2.1-jre
* [MNG-8154] - Upgrade default plugin bindings

Have fun!
- The Maven Team

[ANN] Maven Release 3.1.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Release version 3.1.0.


https://maven.apache.org/maven-release/


Release Notes - Maven Release - Version 3.1.0

** Bug
* [MRELEASE-1064] - [REGRESSION] release:branch uses @releaseLabel 
instead of @branchName in default SCM commit
* [MRELEASE-1109] - update-versions removes the CI-friendly 
${revisions}
* [MRELEASE-1146] - maven-release-plugin tests do not properly 
check for existence of svn command
* [MRELEASE-1147] - @junitVersion@ never replaced in UTs (make 
explicit)

* [MRELEASE-1148] - Release Manager pulls in transitive dependencies

** Improvement
* [MRELEASE-1134] - Pass interactive flag to ScmProvider
* [MRELEASE-1139] - Improve logging for used credentials in 
DefaultScmRepositoryConfigurator


** Dependency upgrade
* [MRELEASE-1128] - maven-scm to 2.0.1
* [MRELEASE-1136] - Upgrade parent POM to version 41
* [MRELEASE-1144] - Upgrade to Parent 42
* [MRELEASE-1145] - Upgrade to Maven 3.6.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Project Info Reports Plugin 3.6.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Project Info Reports Plugin version 3.6.0.


https://maven.apache.org/plugins/maven-project-info-reports-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-project-info-reports-plugin
  3.6.0



Release Notes - Maven Project Info Reports Plugin - Version 3.6.0

** New Feature
* [MPIR-455] - dependencies goal: add support for multi-release JARs

** Improvement
* [MPIR-451] - Rename "Dependency Information" to "Maven Coordinates"
* [MPIR-460] - Dependency Information for maven-plugin

** Task
* [MPIR-459] - Refresh download page

** Dependency upgrade
* [MPIR-457] - Upgrade to Parent 42 and Maven 3.6.3
* [MPIR-461] - Upgrade plugins and components (in ITs)


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Problem building only one subproject with ${revision}

[PavelTurk]

I tried in main pom.xml:

    
    
    
    org.project
    project-api
    ${project.version}
    
    
    

and in project-foo-bar/pom.xml

    
    
    org.project
    project-api
    ${project.version}
    
    

But it didn't help.

Best regards, Pavel

On 6/16/24 6:24 PM, Lasse Lindqvist wrote:


https://maven.apache.org/maven-ci-friendly.html#dependencies 
 says you should 
use project.version as the variable. So try that if you haven't already.


su 16. kesäk. 2024 klo 18.07 Tommy Svensson mailto:to...@natusoft.se>> kirjoitti:

Well this:

The following artifacts could not be resolved: 
org.project:project:pom:${revision} (absent):

Says that maven does not resolve ${revision} to a value.

I want to set project version for all modules and their children only in 
one place - in properties of the main pom.xml

I’ve tried to accomplish the same myself, but gave upp! Even if you have a 
top pom and all other artifacts are sub-modules to that, it does not work! I 
spent a lot of time trying to make this work, but finally just gave upp. And I 
have been using maven for a very long time!

If anyone know a way to accomplish this without writing a tool that 
generates POM:s, please share it here :-).

And NO, don’t ever get an idea to write a tool that generates POM:s! That 
was a joke OK! :-)



Tommy Svensson
to...@natusoft.se 



Från: PavelTurk mailto:pavelturk2...@gmail.com>>
Svara: Maven Users List mailto:users@maven.apache.org>>
Datum: 16 juni 2024 at 16:21:00
Till: users@maven.apache.org  mailto:users@maven.apache.org>>
Ämne:  Problem building only one subproject with ${revision}

Hello all,

I have a project (https://github.com/PavelTurk/maven-revision-test 
 ) with subprojetcs and I 
want to set project version for all
modules and their children only in one place - in properties of the main 
pom.xml. The project  has the following structure:

Project
|-- project-api
|-- project-foo
    |-- project-foo-bar (uses project-api)

In Project/pom.xml I have:

    
    1.0.0
    

    
    project-foo
    project-api
    

    
    
    
    org.project
project-api
    ${revision}
    
    
    

In Project/project-foo/project-foo-bar/pom.xml I have:


    
    org.project
    project-api
    


When I build whole project (via mvn clean install in Project folder) then 
all modules are built without any problems.
However, when I want to build only ONE SUBPROJECT - project-foo-bar (via 
mvn clean install in Project/project-foo/project-foo-bar) I get:

[ERROR] Failed to execute goal on project project-foo-bar: Could not resolve 
dependencies for project org.project.foo:project-foo-bar:jar:1.0.0: Failed to collect 
dependencies at org.project:project-api:jar:1.0.0: Failed to read artifact descriptor 
for org.project:project-api:jar:1.0.0: The following artifacts could not be resolved: 
org.project:project:pom:${revision} (absent): org.project:project:pom:${revision} was 
not found in https://repo.maven.apache.org/maven2 
 during a previous attempt. This failure was 
cached in the local repository and resolution is not reattempted until the update 
interval of central has elapsed or updates are forced -> [Help 1]

Could anyone say how to fix it?

Best regards, Pavel

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

For additional commands, e-mail: users-h...@maven.apache.org 

Re: Problem building only one subproject with ${revision}

[Lasse Lindqvist]

https://maven.apache.org/maven-ci-friendly.html#dependencies says you
should use project.version as the variable. So try that if you haven't
already.

su 16. kesäk. 2024 klo 18.07 Tommy Svensson  kirjoitti:

> Well this:
>
> The following artifacts could not be resolved:
> org.project:project:pom:${revision} (absent):
>
> Says that maven does not resolve ${revision} to a value.
>
> I want to set project version for all modules and their children only in
> one place - in properties of the main pom.xml
>
> I’ve tried to accomplish the same myself, but gave upp! Even if you have a
> top pom and all other artifacts are sub-modules to that, it does not work!
> I spent a lot of time trying to make this work, but finally just gave upp.
> And I have been using maven for a very long time!
>
> If anyone know a way to accomplish this without writing a tool that
> generates POM:s, please share it here :-).
>
> And NO, don’t ever get an idea to write a tool that generates POM:s! That
> was a joke OK! :-)
>
>
>
> Tommy Svensson
> to...@natusoft.se
>
>
>
> Från: PavelTurk 
> Svara: Maven Users List 
> Datum: 16 juni 2024 at 16:21:00
> Till: users@maven.apache.org 
> Ämne:  Problem building only one subproject with ${revision}
>
> Hello all,
>
> I have a project (https://github.com/PavelTurk/maven-revision-test ) with
> subprojetcs and I want to set project version for all
> modules and their children only in one place - in properties of the main
> pom.xml. The project  has the following structure:
>
> Project
> |-- project-api
> |-- project-foo
> |-- project-foo-bar (uses project-api)
>
> In Project/pom.xml I have:
>
> 
> 1.0.0
> 
>
> 
> project-foo
> project-api
> 
>
> 
> 
> 
> org.project
> project-api
> ${revision}
> 
> 
> 
>
> In Project/project-foo/project-foo-bar/pom.xml I have:
>
> 
> 
> org.project
> project-api
> 
> 
>
> When I build whole project (via mvn clean install in Project folder) then
> all modules are built without any problems.
> However, when I want to build only ONE SUBPROJECT - project-foo-bar (via
> mvn clean install in Project/project-foo/project-foo-bar) I get:
>
> [ERROR] Failed to execute goal on project project-foo-bar: Could not
> resolve dependencies for project org.project.foo:project-foo-bar:jar:1.0.0:
> Failed to collect dependencies at org.project:project-api:jar:1.0.0: Failed
> to read artifact descriptor for org.project:project-api:jar:1.0.0: The
> following artifacts could not be resolved:
> org.project:project:pom:${revision} (absent):
> org.project:project:pom:${revision} was not found in
> https://repo.maven.apache.org/maven2 during a previous attempt. This
> failure was cached in the local repository and resolution is not
> reattempted until the update interval of central has elapsed or updates are
> forced -> [Help 1]
>
> Could anyone say how to fix it?
>
> Best regards, Pavel
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Problem building only one subproject with ${revision}

[PavelTurk]

I did it. If you try to build whole project - it will be build and now project 
version is set only in one place - in main pom.xml -
see the link I provided to github project.

The problem is that when you are working on one module you need to rebuild only 
it (using IDE key combinations).
And here as I wrote I have a problem.

So, if anyone helps to fix it, there will be a complete solution.

Best regards, Pavel

On 6/16/24 6:06 PM, Tommy Svensson wrote:


Well this:

|The following artifacts could not be resolved: 
org.project:project:pom:${revision} (absent):|

Says that maven does not resolve |${revision}| to a value.

|I want to set project version for all modules and their children only in one 
place - in properties of the main pom.xml|

I’ve tried to accomplish the same myself, but gave upp! Even if you have a top 
pom and all other artifacts are sub-modules to that, it does not work! I spent 
a lot of time trying to make this work, but finally just gave upp. And I have 
been using maven for a very long time!

If anyone know a way to accomplish this without writing a tool that generates 
POM:s, please share it here :-).

And *NO*, don’t ever get an idea to write a tool that generates POM:s! That was 
a joke OK! :-)



Tommy Svensson

to...@natusoft.se 




Från: PavelTurk  
Svara: Maven Users List  
Datum: 16 juni 2024 at 16:21:00
Till: users@maven.apache.org  

Ämne: Problem building only one subproject with ${revision}


Hello all,

I have a project (https://github.com/PavelTurk/maven-revision-test ) with 
subprojetcs and I want to set project version for all
modules and their children only in one place - in properties of the main 
pom.xml. The project  has the following structure:

Project
|-- project-api
|-- project-foo
    |-- project-foo-bar (uses project-api)

In Project/pom.xml I have:

    
    1.0.0
    

    
    project-foo
    project-api
    

    
    
    
org.project
project-api
${revision}
    
    
    

In Project/project-foo/project-foo-bar/pom.xml I have:


    
    org.project
    project-api
    


When I build whole project (via mvn clean install in Project folder) then all 
modules are built without any problems.
However, when I want to build only ONE SUBPROJECT - project-foo-bar (via mvn 
clean install in Project/project-foo/project-foo-bar) I get:

[ERROR] Failed to execute goal on project project-foo-bar: Could not resolve 
dependencies for project org.project.foo:project-foo-bar:jar:1.0.0: Failed to 
collect dependencies at org.project:project-api:jar:1.0.0: Failed to read artifact 
descriptor for org.project:project-api:jar:1.0.0: The following artifacts could 
not be resolved: org.project:project:pom:${revision} (absent): 
org.project:project:pom:${revision} was not found in 
https://repo.maven.apache.org/maven2 during a previous attempt. This failure was 
cached in the local repository and resolution is not reattempted until the update 
interval of central has elapsed or updates are forced -> [Help 1]

Could anyone say how to fix it?

Best regards, Pavel

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Problem building only one subproject with ${revision}

[Tommy Svensson]

Well this:

The following artifacts could not be resolved: 
org.project:project:pom:${revision} (absent):

Says that maven does not resolve ${revision} to a value.

I want to set project version for all modules and their children only in one 
place - in properties of the main pom.xml

I’ve tried to accomplish the same myself, but gave upp! Even if you have a top 
pom and all other artifacts are sub-modules to that, it does not work! I spent 
a lot of time trying to make this work, but finally just gave upp. And I have 
been using maven for a very long time!

If anyone know a way to accomplish this without writing a tool that generates 
POM:s, please share it here :-).

And NO, don’t ever get an idea to write a tool that generates POM:s! That was a 
joke OK! :-)



Tommy Svensson
to...@natusoft.se



Från: PavelTurk 
Svara: Maven Users List 
Datum: 16 juni 2024 at 16:21:00
Till: users@maven.apache.org 
Ämne:  Problem building only one subproject with ${revision}

Hello all,  

I have a project (https://github.com/PavelTurk/maven-revision-test ) with 
subprojetcs and I want to set project version for all  
modules and their children only in one place - in properties of the main 
pom.xml. The project  has the following structure:  

Project  
|-- project-api  
|-- project-foo  
    |-- project-foo-bar (uses project-api)  

In Project/pom.xml I have:  

      
    1.0.0  
      

      
    project-foo  
    project-api  
      

      
      
      
    org.project  
    project-api  
    ${revision}  
      
      
      

In Project/project-foo/project-foo-bar/pom.xml I have:  

  
      
    org.project  
    project-api  
      
  

When I build whole project (via mvn clean install in Project folder) then all 
modules are built without any problems.  
However, when I want to build only ONE SUBPROJECT - project-foo-bar (via mvn 
clean install in Project/project-foo/project-foo-bar) I get:  

[ERROR] Failed to execute goal on project project-foo-bar: Could not resolve 
dependencies for project org.project.foo:project-foo-bar:jar:1.0.0: Failed to 
collect dependencies at org.project:project-api:jar:1.0.0: Failed to read 
artifact descriptor for org.project:project-api:jar:1.0.0: The following 
artifacts could not be resolved: org.project:project:pom:${revision} (absent): 
org.project:project:pom:${revision} was not found in 
https://repo.maven.apache.org/maven2 during a previous attempt. This failure 
was cached in the local repository and resolution is not reattempted until the 
update interval of central has elapsed or updates are forced -> [Help 1]  

Could anyone say how to fix it?  

Best regards, Pavel  

-  
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org  
For additional commands, e-mail: users-h...@maven.apache.org  

Problem building only one subproject with ${revision}

[PavelTurk]

Hello all,

I have a project (https://github.com/PavelTurk/maven-revision-test ) with 
subprojetcs and I want to set project version for all
modules and their children only in one place - in properties of the main 
pom.xml. The project  has the following structure:

Project
|-- project-api
|-- project-foo
    |-- project-foo-bar (uses project-api)

In Project/pom.xml I have:

    
    1.0.0
    

    
    project-foo
    project-api
    

    
    
    
    org.project
    project-api
    ${revision}
    
    
    

In Project/project-foo/project-foo-bar/pom.xml I have:


    
    org.project
    project-api
    


When I build whole project (via mvn clean install in Project folder) then all 
modules are built without any problems.
However, when I want to build only ONE SUBPROJECT - project-foo-bar (via mvn 
clean install in Project/project-foo/project-foo-bar) I get:

[ERROR] Failed to execute goal on project project-foo-bar: Could not resolve 
dependencies for project org.project.foo:project-foo-bar:jar:1.0.0: Failed to 
collect dependencies at org.project:project-api:jar:1.0.0: Failed to read artifact 
descriptor for org.project:project-api:jar:1.0.0: The following artifacts could 
not be resolved: org.project:project:pom:${revision} (absent): 
org.project:project:pom:${revision} was not found in 
https://repo.maven.apache.org/maven2 during a previous attempt. This failure was 
cached in the local repository and resolution is not reattempted until the update 
interval of central has elapsed or updates are forced -> [Help 1]

Could anyone say how to fix it?

Best regards, Pavel

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Surefire 3.3.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Surefire version 3.3.0.


https://maven.apache.org/surefire/


Release Notes - Maven Surefire - Version 3.3.0

** Bug
* [SUREFIRE-1939] - Build fails if java.home has <=2 path components
* [SUREFIRE-2232] - [REGRESSION] StatelessXmlReporter fails to 
process failed result without a throwable
* [SUREFIRE-2240] - Using JUnit BOM prevents upgrading the engine 
version via plugin dependency


** Improvement
* [SUREFIRE-2248] - Make "type" attribute on failures and errors in 
(surefire|failsafe)-test-report schema optional


** Test
* [SUREFIRE-2141] - Surefire 3.0.0-M8 tests don't pass on Mac M1 
(Surefire1295AttributeJvmCrashesToTestsIT)



** Task
* [SUREFIRE-2244] - Make IT for SUREFIRE-1295 reliable
* [SUREFIRE-2246] - Clean up dependencies reported by 
dependencies:analyze


** Dependency upgrade
* [SUREFIRE-2047] - Upgrade to maven-common-artifact-filters 3.4.0
* [SUREFIRE-2243] - Upgrade commons-io:commons-io to 2.16.0
* [SUREFIRE-2245] - Upgrade to Parent 42 and Maven 3.6.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: central repository not overridden when chaining BOMs

[Nick Stolwijk]

Hi Mattia,

Redefining the repository is an unusual way of using a mirror. I don't know
if it solves your problem, but have you tried to define the mirror instead
of a repository? See
https://maven.apache.org/guides/mini/guide-mirror-settings.html

Hope this helps,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Fri, 14 Jun 2024 at 15:54, mattia fattorello 
wrote:

> Hello,
> First time using a mailing list so forgive (and correct) me if I do
> something wrong.
> I read that before opening an issue it is better to check with the mailing
> list, so here I am.
>
> In our company we have our own artifactory repositories defined as follows
> in settings.xml:
> '''
> 
>   ...
>   
> 
>   
> 
>   
> false
>   
>   central
>   libs-release
>   .../artifactory/libs-release
> 
> 
>   
>   snapshots
>   libs-snapshot
>   .../artifactory/libs-snapshot
> 
>   
>   [...]
>   artifactory
> 
>   
>
>   
> artifactory
>   
> 
> '''
> We never had problems with this setup but now we are trying to do this:
> Have a project that define in the dependencyManagement a BOM (built by us)
> (BOM 1, 0.1.0-SNAPSHOT)
> That BOM has another BOM in its dependencyManagement (again built by us)
> (BOM 2, 2.0.3)
>
> Previously the project was just pointing to BOM2, now we have BOM1.
> When building maven fails as it's unable to find BOM2. debugging I see:
>
> [DEBUG] Resolving artifact my.company:bom1:pom:0.1.0-20240614.085416-4 from
> [central (.../artifactory/libs-release
> , default,
> releases), snapshots (.../artifactory/libs-snapshot
> , default,
> releases+snapshots)]
>
> [...]
>
> [DEBUG] Resolving artifact my.company:bom2:pom:2.0.3 from [snapshots (
> .../artifactory/libs-snapshot
> , default,
> releases+snapshots), central (https://repo.maven.apache.org/maven2,
> default, releases)]
>
> I tried renaming the repositories id to my-central and my-snapshots and I
> get
>
> [DEBUG] Resolving my-company:bom2:pom:2.0.3 from [my-central (
> .../artifactory/libs-release
> , default,
> releases), my-snapshots (.../artifactory/libs-snapshot
> , default,
> releases+snapshots), central (https://repo.maven.apache.org/maven2,
> default, releases)]
>
> But I don't understand why, only for the BOM dependency inside another BOM,
> the central repository is not overridden.
> Thanks for any help.
> Mattia
>

central repository not overridden when chaining BOMs

[mattia fattorello]

Hello,
First time using a mailing list so forgive (and correct) me if I do
something wrong.
I read that before opening an issue it is better to check with the mailing
list, so here I am.

In our company we have our own artifactory repositories defined as follows
in settings.xml:
'''

  ...
  

  

  
false
  
  central
  libs-release
  .../artifactory/libs-release


  
  snapshots
  libs-snapshot
  .../artifactory/libs-snapshot

  
  [...]
  artifactory

  

  
artifactory
  

'''
We never had problems with this setup but now we are trying to do this:
Have a project that define in the dependencyManagement a BOM (built by us)
(BOM 1, 0.1.0-SNAPSHOT)
That BOM has another BOM in its dependencyManagement (again built by us)
(BOM 2, 2.0.3)

Previously the project was just pointing to BOM2, now we have BOM1.
When building maven fails as it's unable to find BOM2. debugging I see:

[DEBUG] Resolving artifact my.company:bom1:pom:0.1.0-20240614.085416-4 from
[central (.../artifactory/libs-release
, default,
releases), snapshots (.../artifactory/libs-snapshot
, default,
releases+snapshots)]

[...]

[DEBUG] Resolving artifact my.company:bom2:pom:2.0.3 from [snapshots (
.../artifactory/libs-snapshot
, default,
releases+snapshots), central (https://repo.maven.apache.org/maven2,
default, releases)]

I tried renaming the repositories id to my-central and my-snapshots and I
get

[DEBUG] Resolving my-company:bom2:pom:2.0.3 from [my-central (
.../artifactory/libs-release
, default,
releases), my-snapshots (.../artifactory/libs-snapshot
, default,
releases+snapshots), central (https://repo.maven.apache.org/maven2,
default, releases)]

But I don't understand why, only for the BOM dependency inside another BOM,
the central repository is not overridden.
Thanks for any help.
Mattia

Re: Maven version for remote build cache extension

[Guillaume Nodet]

Afaik, it will only work with 3.9.x.

Le ven. 14 juin 2024 à 08:51, Debraj Manna  a
écrit :

> Hi
>
> Can someone let me know which version of Maven is supported with
> remote-build-cache-extension
> ? Is it
> recommended to use Maven 3.8.8 with 1.1.0 build cache?
>
> Thanks
> Debraj
>


-- 

Guillaume Nodet

Maven version for remote build cache extension

[Debraj Manna]

Hi

Can someone let me know which version of Maven is supported with
remote-build-cache-extension
? Is it
recommended to use Maven 3.8.8 with 1.1.0 build cache?

Thanks
Debraj

Re: Apache Maven mvnd 1.0.0 "early access"

[Tamás Cservenák]

New builds w/ fixed deprecation warning about JAnsi will land here:
https://github.com/apache/maven-mvnd/actions/runs/9505851154

Thanks
T

On Thu, Jun 13, 2024 at 7:23 PM Tamás Cservenák  wrote:

> Howdy,
>
> Just wanted to mention that the upcoming Apache Maven mvnd
> 1.0.0(-SNAPSHOT) integrated with latest Apache Maven 3.9.8 (currently under
> vote, is in the process of release) is available for all supported
> platforms from Github, Go grab one while hot!
>
> (and test and report back issues, please and thanks!)
>
> https://github.com/apache/maven-mvnd/actions/runs/950209
>
> Thanks
> T
>

Apache Maven mvnd 1.0.0 "early access"

[Tamás Cservenák]

Howdy,

Just wanted to mention that the upcoming Apache Maven mvnd 1.0.0(-SNAPSHOT)
integrated with latest Apache Maven 3.9.8 (currently under vote, is in the
process of release) is available for all supported platforms from Github,
Go grab one while hot!

(and test and report back issues, please and thanks!)

https://github.com/apache/maven-mvnd/actions/runs/950209

Thanks
T

Upcoming Maven 3.9.8

[Tamás Cservenák]

Howdy,

The current status of Maven 3.9.8:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.8

I plan to release it soon. If anyone has anything to add, please let me
know.

Upcoming in the pipe:
- mvnd 1.x (former m39, mvnd that uses Maven 3.9.8) - did not check latest
issues/PRs, but I might release it along with Maven 3.9.8
- Resolver 2.0.0 (unsure do we want a beta out of it, as really almost all
the issues are done)

Thanks
T

[ANN] Release Maven Dependency Plugin 3.7.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Dependency Plugin version 3.7.0.


https://maven.apache.org/plugins/maven-dependency-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-dependency-plugin
  3.7.0



Release Notes - Maven Dependency Plugin - Version 3.7.0

** Bug
* [MDEP-835] - dependency:tree no longer shows optional flag
* [MDEP-838] - "Artifact has not been packaged yet" error message 
is not very helpful
* [MDEP-938] - 'mdep.overIfNewer' is misnamed from its usage of 
'mdep.overWriteIfNewer'


** New Feature
* [MDEP-317] - Add goal dependency:analyze-exclusions - check for 
invalid excludes
* [MDEP-799] - improve mvn dependency:tree - add optional JSON 
output of the results

* [MDEP-928] - Allow to exclude classes from dependency:analyze

** Improvement
* [MDEP-669] - Optimize the documentation of  of 
build-classpath-mojo

* [MDEP-893] - Get rid of commons-lang3
* [MDEP-894] - Use @Component instead of @Parameter for session/project
* [MDEP-896] - Removing unused code
* [MDEP-897] - Remove old style JavaDoc Plexus docs
* [MDEP-899] - Upgrade maven-plugin parent to 42
* [MDEP-917] - dependency:analyze-exclusions - use Resolver API 
instead of ProjectBuilder
* [MDEP-924] - Get rid of maven-artifact-transfer from list-classes 
goal

* [MDEP-925] - Require Maven 3.6.3
* [MDEP-939] - Lock down classifier in dependency:sources goal

** Test
* [MDEP-710] - reenable TestTreeMojo

** Task
* [MDEP-912] - Use version for plexus-utils/plexus-xml  from parent
* [MDEP-914] - collect goal description broken in documentation
* [MDEP-918] - Use standard updatePolicy for repositories in ITs
* [MDEP-923] - Code cleanups
* [MDEP-935] - Improvement ITs for dependency:tree
* [MDEP-941] - Deprecate dependency:sources in favor of 
dependency:resolve-sources


** Dependency upgrade
* [MDEP-911] - Bump org.codehaus.plexus:plexus-archiver from 4.8.0 
to 4.9.2

* [MDEP-915] - Upgrade commons-io:commons-io from 2.15.1 to 2.16.1
* [MDEP-920] - Bump org.assertj:assertj-core from 3.24.2 to 3.26.0
* [MDEP-921] - Bump org.apache.commons:commons-text from 1.11.0 to 
1.12.0
* [MDEP-922] - dependency:analyze-exclusions - should report issue 
only in current project
* [MDEP-929] - Bump 
org.apache.maven.shared:maven-dependency-analyzer from 1.13.2 to 1.14.1
* [MDEP-936] - Bump org.apache.maven.shared:maven-dependency-tree 
from 3.2.1 to 3.3.0



Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Shared Resources, version 6 Released

[Slawomir Jaranowski]

The Maven team is pleased to announce the release of the Apache Maven
Shared Resources, version 6

This is a collection of templates that are specific to the Maven project.

https://maven.apache.org/shared/maven-shared-resources/

You should specify the version in your project's plugin dependency:


 org.apache.maven.shared
 maven-shared-resources
 6


Release Notes - Maven Shared Components - Version maven-shared-resources-6

** New Feature
* [MSHARED-1171] - New IntelliJ code style formatter

** Improvement
* [MSHARED-1401] - Refresh checkstyle rules
* [MSHARED-1408] - Refresh IntelliJ formater
* [MSHARED-1409] - Fix site links

** Dependency upgrade
* [MSHARED-1170] - Upgrade Parent to 42
* [MSHARED-1353] - Upgrade parent POM to version 41

Enjoy,
-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven PMD Plugin 3.23.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
PMD Plugin version 3.23.0.


https://maven.apache.org/plugins/maven-pmd-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-pmd-plugin
  3.23.0



Release Notes - Maven PMD Plugin - Version 3.23.0

** Bug
* [MPMD-395] - Build doesn't fail for invalid CPD format

** Dependency upgrade
* [MPMD-397] - Upgrade to Maven 3.6.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Re: Custom auth plugin/extension - how to?

[David Grieve]

A “maven-rfc” repo is a good idea if the issue of governance can be worked out. 
There will be a good deal of overhead related to maintaining, gatekeeping, and 
administration of such a repository. If RFC’s were just specs with problem 
statements, decision records that might be easier. An RFC should also be 
sponsored/owned by a committer. The work could happen in a fork somewhere that 
was established by the sponsor who could then manage whether to leave it wide 
open for contribution or to a select few.

As for Bernd’s question and the “Handling sensitive data in Maven” wiki, 
couldn’t this problem be solved by injecting an implementation of 
org.apache.maven.settings.building.SettingsBuilder to suite your needs? For 
example, I could have a SettingsBuilder that gets settings from some on-line 
storage (imagine a build environment where “settings.xml" is centralized).

On 2024/06/05 20:31:40 Tamás Cservenák wrote:
> Asf wiki is not the best place for brainstorming, as is usable only for
> people w asf accounts (i guess).
>
> What if we create a repo like "maven-rfc", where anyone can raise PRs (new
> functionality, change requests or just ideas), these would be like
> "proposals", that we discuss and modify specs w PRs, and once proposal
> considered "complete", it can be moved to "to be implemented" state (those
> could be plain directories), maybe even version those things?
>
> And then implementation can happen based on documented
> requirements/functionality?
>
> T
>
> On Wed, Jun 5, 2024, 20:27 Tamás Cservenák 
> mailto:ta...@cservenak.net>> wrote:
>
> > Howdy,
> >
> > Bernd, I would be very interested to collect some ideas to solve exactly
> > this problem...
> > When I revamped maven-gpg-plugin re "worst practices", I started tinkering
> > about this...
> >
> > Created page just to gather ideas...
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Handling+sensitive+data+in+Maven
> >
> > Unsure is this editable for you... we may want some other place for
> > brainstorming?
> >
> > Thanks
> > T
> >
> > On Wed, Jun 5, 2024 at 7:24 PM Bernd Eckenfels 
> > mailto:ec...@zusammenkunft.net>>
> > wrote:
> >
> >> BTW Speaking of “custom”, I would be very interested in
> >> a token based authentication, at least for read access to
> >> our repository server and mirror, we currently ship a static
> >> read-only login, and also we don’t want to allow putting
> >> their write (LDAP Login) credentials into files.
> >>
> >> If the maven ecosystem would have a OS/Token method
> >> like requestin a JWT token from a distribution point which
> >> uses native Kerberos SSPI or user certificates that would
> >> greatly improve this,
> >>
> >> What’s your plan for that auth, can you upstream it?
> >>
> >> Gruß
> >> Bernd
> >>
> >> David Grieve wrote on 4. June 2024 20:33 (GMT +02:00):
> >>
> >> > Thank you for the hint, Tamás.
> >> >
> >> > The problem I’m trying to solve is that I want a custom Authentication
> >> > for a particular server. I do not want to re-implement HttpTransporter.
> >> > Here are the important bits of what I’ve come up with.
> >> > --
> >> > public class MyTransporterFactory implements TransporterFactory {
> >> >
> >> > // copied from
> >> > org.eclipse.aether.transport.http.HttpTransporterFactory
> >> > private static Map
> >> > getManuallyCreatedExtractors() {
> >> > HashMap map = new HashMap<>();
> >> > map.put(Nexus2ChecksumExtractor.NAME, new
> >> > Nexus2ChecksumExtractor());
> >> > map.put(XChecksumChecksumExtractor.NAME, new
> >> > XChecksumChecksumExtractor());
> >> > return Collections.unmodifiableMap(map);
> >> > }
> >> >
> >> > // I’m not happy with this...
> >> > private final HttpTransporterFactory httpTransporterFactory = new
> >> > HttpTransporterFactory(getManuallyCreatedExtractors());
> >> >
> >> > @Override
> >> > public Transporter newInstance(RepositorySystemSession session,
> >> > RemoteRepository repository)  throws NoTransporterException {
> >> >
> >> > if (requiresSpecialAuth(repository)) {
> >> > repository = new RemoteRepository.Builder(repository)
> >> > .setAuthentication(new MyAuthentication(repository))
> >> > .build();
> >> > }
> >> > return httpTransporterFactory.newInstance(session, repository);
> >> > }
> >> > --
> >> >
> >> > Then “MyAuthentication” does the right thing for the fill method.
> >> >
> >> > This approach is working for me, but I’d be interested to know if there
> >> > is a better way. I do not want to re-implement HttpTransport!
> >> >
> >> >
> >> > On 2024/06/03 20:25:48 Tamás Cservenák wrote:
> >> >> Howdy,
> >> >>
> >> >> What are you trying to do? You may go better if you implement custom
> >> >> (resolver) transport maybe?
> >> —
> >> https://bernd.eckenfels.net
> >>
> >> 

[ANN] Apache Maven Common Artifact Filters 3.4.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Common Artifact Filters version 3.4.0.


https://maven.apache.org/shared/maven-common-artifact-filters/


Release Notes - Maven Shared Components - Version 
maven-common-artifact-filters-3.4.0


** Bug
* [MSHARED-1300] - Order of dependencies is not always retained 
when filtering


** Improvement
* [MSHARED-1303] - Declare and undeclare used and unused dependencies

** Dependency upgrade
* [MSHARED-1301] - Upgrade to Parent 42 and Maven 3.6.3
* [MSHARED-1302] - commons-io to 2.13.0


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Transfer failed in an IPv6-only (+NAT64) environment

[Willy Manga]

Hi,

.On 05/06/2024 11:48, Tamás Cservenák wrote:

Howdy,

Thanks for sharing!

PS: We are not authoring the JDK bug, but good to have this in list.


Can someone with write permission update that page
https://cwiki.apache.org/confluence/display/MAVEN/ConnectException

with more up to  date alternatives?




On Wed, Jun 5, 2024 at 8:49 AM Willy Manga  wrote:


.
On 31/05/2024 17:46, Willy Manga wrote:

Hi,

On 31/05/2024 17:11, Tamás Cservenák wrote:

And one more hint:

See https://bugs.openjdk.org/browse/JDK-8311547
and read about java.net.preferIPv6Addresses Java system property...

Also, try to invoke Maven as:
MAVEN_OPTS="-Djava.net.preferIPv6Addresses=true" mvn package -X


java.net.preferIPv6Addresses=system

is even better. You let the OS handle that part.


[...]
--
Willy Manga


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Custom auth plugin/extension - how to?

[Tamás Cservenák]

Asf wiki is not the best place for brainstorming, as is usable only for
people w asf accounts (i guess).

What if we create a repo like "maven-rfc", where anyone can raise PRs (new
functionality, change requests or just ideas), these would be like
"proposals", that we discuss and modify specs w PRs, and once proposal
considered "complete", it can be moved to "to be implemented" state (those
could be plain directories), maybe even version those things?

And then implementation can happen based on documented
requirements/functionality?

T

On Wed, Jun 5, 2024, 20:27 Tamás Cservenák  wrote:

> Howdy,
>
> Bernd, I would be very interested to collect some ideas to solve exactly
> this problem...
> When I revamped maven-gpg-plugin re "worst practices", I started tinkering
> about this...
>
> Created page just to gather ideas...
>
> https://cwiki.apache.org/confluence/display/MAVEN/Handling+sensitive+data+in+Maven
>
> Unsure is this editable for you... we may want some other place for
> brainstorming?
>
> Thanks
> T
>
> On Wed, Jun 5, 2024 at 7:24 PM Bernd Eckenfels 
> wrote:
>
>> BTW Speaking of “custom”, I would be very interested in
>> a token based authentication, at least for read access to
>> our repository server and mirror, we currently ship a static
>> read-only login, and also we don’t want to allow putting
>> their write (LDAP Login) credentials into files.
>>
>> If the maven ecosystem would have a OS/Token method
>> like requestin a JWT token from a distribution point which
>> uses native Kerberos SSPI or user certificates that would
>> greatly improve this,
>>
>> What’s your plan for that auth, can you upstream it?
>>
>> Gruß
>> Bernd
>>
>> David Grieve wrote on 4. June 2024 20:33 (GMT +02:00):
>>
>> > Thank you for the hint, Tamás.
>> >
>> > The problem I’m trying to solve is that I want a custom Authentication
>> > for a particular server. I do not want to re-implement HttpTransporter.
>> > Here are the important bits of what I’ve come up with.
>> > --
>> > public class MyTransporterFactory implements TransporterFactory {
>> >
>> > // copied from
>> > org.eclipse.aether.transport.http.HttpTransporterFactory
>> > private static Map
>> > getManuallyCreatedExtractors() {
>> > HashMap map = new HashMap<>();
>> > map.put(Nexus2ChecksumExtractor.NAME, new
>> > Nexus2ChecksumExtractor());
>> > map.put(XChecksumChecksumExtractor.NAME, new
>> > XChecksumChecksumExtractor());
>> > return Collections.unmodifiableMap(map);
>> > }
>> >
>> > // I’m not happy with this...
>> > private final HttpTransporterFactory httpTransporterFactory = new
>> > HttpTransporterFactory(getManuallyCreatedExtractors());
>> >
>> > @Override
>> > public Transporter newInstance(RepositorySystemSession session,
>> > RemoteRepository repository)  throws NoTransporterException {
>> >
>> > if (requiresSpecialAuth(repository)) {
>> > repository = new RemoteRepository.Builder(repository)
>> > .setAuthentication(new MyAuthentication(repository))
>> > .build();
>> > }
>> > return httpTransporterFactory.newInstance(session, repository);
>> > }
>> > --
>> >
>> > Then “MyAuthentication” does the right thing for the fill method.
>> >
>> > This approach is working for me, but I’d be interested to know if there
>> > is a better way. I do not want to re-implement HttpTransport!
>> >
>> >
>> > On 2024/06/03 20:25:48 Tamás Cservenák wrote:
>> >> Howdy,
>> >>
>> >> What are you trying to do? You may go better if you implement custom
>> >> (resolver) transport maybe?
>> —
>> https://bernd.eckenfels.net
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: Custom auth plugin/extension - how to?

[Tamás Cservenák]

Howdy,

Bernd, I would be very interested to collect some ideas to solve exactly
this problem...
When I revamped maven-gpg-plugin re "worst practices", I started tinkering
about this...

Created page just to gather ideas...
https://cwiki.apache.org/confluence/display/MAVEN/Handling+sensitive+data+in+Maven

Unsure is this editable for you... we may want some other place for
brainstorming?

Thanks
T

On Wed, Jun 5, 2024 at 7:24 PM Bernd Eckenfels 
wrote:

> BTW Speaking of “custom”, I would be very interested in
> a token based authentication, at least for read access to
> our repository server and mirror, we currently ship a static
> read-only login, and also we don’t want to allow putting
> their write (LDAP Login) credentials into files.
>
> If the maven ecosystem would have a OS/Token method
> like requestin a JWT token from a distribution point which
> uses native Kerberos SSPI or user certificates that would
> greatly improve this,
>
> What’s your plan for that auth, can you upstream it?
>
> Gruß
> Bernd
>
> David Grieve wrote on 4. June 2024 20:33 (GMT +02:00):
>
> > Thank you for the hint, Tamás.
> >
> > The problem I’m trying to solve is that I want a custom Authentication
> > for a particular server. I do not want to re-implement HttpTransporter.
> > Here are the important bits of what I’ve come up with.
> > --
> > public class MyTransporterFactory implements TransporterFactory {
> >
> > // copied from
> > org.eclipse.aether.transport.http.HttpTransporterFactory
> > private static Map
> > getManuallyCreatedExtractors() {
> > HashMap map = new HashMap<>();
> > map.put(Nexus2ChecksumExtractor.NAME, new
> > Nexus2ChecksumExtractor());
> > map.put(XChecksumChecksumExtractor.NAME, new
> > XChecksumChecksumExtractor());
> > return Collections.unmodifiableMap(map);
> > }
> >
> > // I’m not happy with this...
> > private final HttpTransporterFactory httpTransporterFactory = new
> > HttpTransporterFactory(getManuallyCreatedExtractors());
> >
> > @Override
> > public Transporter newInstance(RepositorySystemSession session,
> > RemoteRepository repository)  throws NoTransporterException {
> >
> > if (requiresSpecialAuth(repository)) {
> > repository = new RemoteRepository.Builder(repository)
> > .setAuthentication(new MyAuthentication(repository))
> > .build();
> > }
> > return httpTransporterFactory.newInstance(session, repository);
> > }
> > --
> >
> > Then “MyAuthentication” does the right thing for the fill method.
> >
> > This approach is working for me, but I’d be interested to know if there
> > is a better way. I do not want to re-implement HttpTransport!
> >
> >
> > On 2024/06/03 20:25:48 Tamás Cservenák wrote:
> >> Howdy,
> >>
> >> What are you trying to do? You may go better if you implement custom
> >> (resolver) transport maybe?
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Custom auth plugin/extension - how to?

[Bernd Eckenfels]

BTW Speaking of “custom”, I would be very interested in
a token based authentication, at least for read access to
our repository server and mirror, we currently ship a static
read-only login, and also we don’t want to allow putting
their write (LDAP Login) credentials into files.

If the maven ecosystem would have a OS/Token method
like requestin a JWT token from a distribution point which
uses native Kerberos SSPI or user certificates that would
greatly improve this,

What’s your plan for that auth, can you upstream it?

Gruß
Bernd

David Grieve wrote on 4. June 2024 20:33 (GMT +02:00):

> Thank you for the hint, Tamás.
> 
> The problem I’m trying to solve is that I want a custom Authentication
> for a particular server. I do not want to re-implement HttpTransporter.
> Here are the important bits of what I’ve come up with.
> --
> public class MyTransporterFactory implements TransporterFactory {
> 
> // copied from
> org.eclipse.aether.transport.http.HttpTransporterFactory
> private static Map
> getManuallyCreatedExtractors() {
> HashMap map = new HashMap<>();
> map.put(Nexus2ChecksumExtractor.NAME, new
> Nexus2ChecksumExtractor());
> map.put(XChecksumChecksumExtractor.NAME, new
> XChecksumChecksumExtractor());
> return Collections.unmodifiableMap(map);
> }
> 
> // I’m not happy with this...
> private final HttpTransporterFactory httpTransporterFactory = new
> HttpTransporterFactory(getManuallyCreatedExtractors());
> 
> @Override
> public Transporter newInstance(RepositorySystemSession session,
> RemoteRepository repository)  throws NoTransporterException {
> 
> if (requiresSpecialAuth(repository)) {
> repository = new RemoteRepository.Builder(repository)
> .setAuthentication(new MyAuthentication(repository))
> .build();
> }
> return httpTransporterFactory.newInstance(session, repository);
> }
> --
> 
> Then “MyAuthentication” does the right thing for the fill method.
> 
> This approach is working for me, but I’d be interested to know if there
> is a better way. I do not want to re-implement HttpTransport!
> 
> 
> On 2024/06/03 20:25:48 Tamás Cservenák wrote:
>> Howdy,
>>
>> What are you trying to do? You may go better if you implement custom
>> (resolver) transport maybe?
— 
https://bernd.eckenfels.net

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Release Maven Help Plugin 3.4.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Help Plugin version 3.4.1.


https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-help-plugin
  3.4.1



Release Notes - Maven Help Plugin - Version 3.4.1

** Test
* [MPH-207] - Exercise output of an expression returning a null object.

** Dependency upgrade
* [MPH-211] - Upgrade maven-plugin parent to 41
* [MPH-213] - Upgrade org.codehaus.plexus:plexus-interactivity-api 
from 1.3

* [MPH-214] - Upgrade to Parent 42


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Checkstyle Plugin 3.4.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Checkstyle Plugin, version 3.4.0.


https://maven.apache.org/plugins/maven-checkstyle-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  >maven-checkstyle-plugin
  3.4.0



Release Notes - Maven Checkstyle Plugin - Version 3.4.0

** Bug
* [MCHECKSTYLE-450] - Checkstyle rule link format results in 404

** New Feature
* [MCHECKSTYLE-449] - Add support for SARIF output format

** Dependency upgrade
* [MCHECKSTYLE-443] - Upgrade to Parent 41
* [MCHECKSTYLE-447] - Upgrade org.codehaus.plexus:plexus-resources 
to 1.3.0

* [MCHECKSTYLE-448] - Upgrade to Parent 42 and Maven 3.6.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [EXTERNAL] Re: Re: Custom auth plugin/extension - how to?

[David Grieve]

Thanks again, Tamás. It is comforting to know that my implementation was not 
far off.

From: Tamás Cservenák 
Date: Wednesday, June 5, 2024 at 3:38 AM
To: Maven Users List 
Subject: [EXTERNAL] Re: Re: Custom auth plugin/extension - how to?

[You don't often get email from ta...@cservenak.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Howdy,

I'd do it as this:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fcstamas%2F5c787875fc3196dbd200e3bd24692c98=05%7C02%7CDavid.Grieve%40microsoft.com%7Cc5e5dc98de28474fb72808dc85328934%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638531699300812986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=GYJefX6wgOXA0SDH%2BuNpHqlYYq9hp26r6bfGRttFrf4%3D=0

Facts:
- make priority higher than than of HTTP - this makes sure your transport
will be always asked before Http one
- just delegate/reuse http transport, no need to reimplement anything (make
it also a JSR330 component!)
- in newInstance there is a check (copied from http transport) to ensure
httpTransport will not throw, then do your thing, and call into
httpTransport

HTH
T

On Tue, Jun 4, 2024 at 8:34 PM David Grieve
 wrote:

> Thank you for the hint, Tamás.
>
> The problem I’m trying to solve is that I want a custom Authentication for
> a particular server. I do not want to re-implement HttpTransporter. Here
> are the important bits of what I’ve come up with.
> --
> public class MyTransporterFactory implements TransporterFactory {
>
> // copied from org.eclipse.aether.transport.http.HttpTransporterFactory
> private static Map
> getManuallyCreatedExtractors() {
> HashMap map = new HashMap<>();
> map.put(Nexus2ChecksumExtractor.NAME, new
> Nexus2ChecksumExtractor());
> map.put(XChecksumChecksumExtractor.NAME, new
> XChecksumChecksumExtractor());
> return Collections.unmodifiableMap(map);
> }
>
> // I’m not happy with this...
> private final HttpTransporterFactory httpTransporterFactory = new
> HttpTransporterFactory(getManuallyCreatedExtractors());
>
> @Override
> public Transporter newInstance(RepositorySystemSession session,
> RemoteRepository repository)  throws NoTransporterException {
>
> if (requiresSpecialAuth(repository)) {
> repository = new RemoteRepository.Builder(repository)
> .setAuthentication(new MyAuthentication(repository))
> .build();
> }
> return httpTransporterFactory.newInstance(session, repository);
> }
> --
>
> Then “MyAuthentication” does the right thing for the fill method.
>
> This approach is working for me, but I’d be interested to know if there is
> a better way. I do not want to re-implement HttpTransport!
>
>
> On 2024/06/03 20:25:48 Tamás Cservenák wrote:
> > Howdy,
> >
> > What are you trying to do? You may go better if you implement custom
> > (resolver) transport maybe?
> >
> > Thanks
> > T
> >
> > On Mon, Jun 3, 2024, 22:22 David Grieve  lid>
> > wrote:
> >
> > > My questions are: Is this doable and, if so, how would one go about it?
> > >
> > > I’m trying to cobble together a plugin/extension that will either get
> an
> > > auth token for resolving an artifact before the artifact is resolved,
> or
> > > will get an auth token if the resolution returns a 401.
> > > The plugin route happens too late in the execution, but I’ve found that
> > > with an AbstractMavenLifecycleParticipant at least afterProjectsRead
> gets
> > > called before artifact resolution. However, I can’t seem to affect the
> > > server password in a way that allows artifact resolution to  succeed.
> > > I’ve also tried overriding some default implementations, but I don’t
> see
> > > the extension getting invoked (I see that Maven is aware of the
> extension,
> > > but it doesn’t get used AFAICT).
> > >
> >
>
>

Re: Transfer failed in an IPv6-only (+NAT64) environment

[Tamás Cservenák]

Howdy,

Thanks for sharing!

PS: We are not authoring the JDK bug, but good to have this in list.

T

On Wed, Jun 5, 2024 at 8:49 AM Willy Manga  wrote:

> .
> On 31/05/2024 17:46, Willy Manga wrote:
> > Hi,
> >
> > On 31/05/2024 17:11, Tamás Cservenák wrote:
> >> And one more hint:
> >>
> >> See https://bugs.openjdk.org/browse/JDK-8311547
> >> and read about java.net.preferIPv6Addresses Java system property...
> >>
> >> Also, try to invoke Maven as:
> >> MAVEN_OPTS="-Djava.net.preferIPv6Addresses=true" mvn package -X
>
> java.net.preferIPv6Addresses=system
>
> is even better. You let the OS handle that part.
>
>
>
> --
> Willy Manga
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Re: Custom auth plugin/extension - how to?

[Tamás Cservenák]

Howdy,

I'd do it as this:
https://gist.github.com/cstamas/5c787875fc3196dbd200e3bd24692c98

Facts:
- make priority higher than than of HTTP - this makes sure your transport
will be always asked before Http one
- just delegate/reuse http transport, no need to reimplement anything (make
it also a JSR330 component!)
- in newInstance there is a check (copied from http transport) to ensure
httpTransport will not throw, then do your thing, and call into
httpTransport

HTH
T

On Tue, Jun 4, 2024 at 8:34 PM David Grieve
 wrote:

> Thank you for the hint, Tamás.
>
> The problem I’m trying to solve is that I want a custom Authentication for
> a particular server. I do not want to re-implement HttpTransporter. Here
> are the important bits of what I’ve come up with.
> --
> public class MyTransporterFactory implements TransporterFactory {
>
> // copied from org.eclipse.aether.transport.http.HttpTransporterFactory
> private static Map
> getManuallyCreatedExtractors() {
> HashMap map = new HashMap<>();
> map.put(Nexus2ChecksumExtractor.NAME, new
> Nexus2ChecksumExtractor());
> map.put(XChecksumChecksumExtractor.NAME, new
> XChecksumChecksumExtractor());
> return Collections.unmodifiableMap(map);
> }
>
> // I’m not happy with this...
> private final HttpTransporterFactory httpTransporterFactory = new
> HttpTransporterFactory(getManuallyCreatedExtractors());
>
> @Override
> public Transporter newInstance(RepositorySystemSession session,
> RemoteRepository repository)  throws NoTransporterException {
>
> if (requiresSpecialAuth(repository)) {
> repository = new RemoteRepository.Builder(repository)
> .setAuthentication(new MyAuthentication(repository))
> .build();
> }
> return httpTransporterFactory.newInstance(session, repository);
> }
> --
>
> Then “MyAuthentication” does the right thing for the fill method.
>
> This approach is working for me, but I’d be interested to know if there is
> a better way. I do not want to re-implement HttpTransport!
>
>
> On 2024/06/03 20:25:48 Tamás Cservenák wrote:
> > Howdy,
> >
> > What are you trying to do? You may go better if you implement custom
> > (resolver) transport maybe?
> >
> > Thanks
> > T
> >
> > On Mon, Jun 3, 2024, 22:22 David Grieve  lid>
> > wrote:
> >
> > > My questions are: Is this doable and, if so, how would one go about it?
> > >
> > > I’m trying to cobble together a plugin/extension that will either get
> an
> > > auth token for resolving an artifact before the artifact is resolved,
> or
> > > will get an auth token if the resolution returns a 401.
> > > The plugin route happens too late in the execution, but I’ve found that
> > > with an AbstractMavenLifecycleParticipant at least afterProjectsRead
> gets
> > > called before artifact resolution. However, I can’t seem to affect the
> > > server password in a way that allows artifact resolution to  succeed.
> > > I’ve also tried overriding some default implementations, but I don’t
> see
> > > the extension getting invoked (I see that Maven is aware of the
> extension,
> > > but it doesn’t get used AFAICT).
> > >
> >
>
>

Re: Transfer failed in an IPv6-only (+NAT64) environment

[Willy Manga]

.
On 31/05/2024 17:46, Willy Manga wrote:

Hi,

On 31/05/2024 17:11, Tamás Cservenák wrote:

And one more hint:

See https://bugs.openjdk.org/browse/JDK-8311547
and read about java.net.preferIPv6Addresses Java system property...

Also, try to invoke Maven as:
MAVEN_OPTS="-Djava.net.preferIPv6Addresses=true" mvn package -X


java.net.preferIPv6Addresses=system

is even better. You let the OS handle that part.



--
Willy Manga


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Re: Custom auth plugin/extension - how to?

[David Grieve]

Thank you for the hint, Tamás.

The problem I’m trying to solve is that I want a custom Authentication for a 
particular server. I do not want to re-implement HttpTransporter. Here are the 
important bits of what I’ve come up with.
--
public class MyTransporterFactory implements TransporterFactory {

// copied from org.eclipse.aether.transport.http.HttpTransporterFactory
private static Map 
getManuallyCreatedExtractors() {
HashMap map = new HashMap<>();
map.put(Nexus2ChecksumExtractor.NAME, new Nexus2ChecksumExtractor());
map.put(XChecksumChecksumExtractor.NAME, new 
XChecksumChecksumExtractor());
return Collections.unmodifiableMap(map);
}

// I’m not happy with this...
private final HttpTransporterFactory httpTransporterFactory = new 
HttpTransporterFactory(getManuallyCreatedExtractors());

@Override
public Transporter newInstance(RepositorySystemSession session, 
RemoteRepository repository)  throws NoTransporterException {

if (requiresSpecialAuth(repository)) {
repository = new RemoteRepository.Builder(repository)
.setAuthentication(new MyAuthentication(repository))
.build();
}
return httpTransporterFactory.newInstance(session, repository);
}
--

Then “MyAuthentication” does the right thing for the fill method.

This approach is working for me, but I’d be interested to know if there is a 
better way. I do not want to re-implement HttpTransport!


On 2024/06/03 20:25:48 Tamás Cservenák wrote:
> Howdy,
>
> What are you trying to do? You may go better if you implement custom
> (resolver) transport maybe?
>
> Thanks
> T
>
> On Mon, Jun 3, 2024, 22:22 David Grieve 
> mailto:da...@microsoft.com.inva>lid>
> wrote:
>
> > My questions are: Is this doable and, if so, how would one go about it?
> >
> > I’m trying to cobble together a plugin/extension that will either get an
> > auth token for resolving an artifact before the artifact is resolved, or
> > will get an auth token if the resolution returns a 401.
> > The plugin route happens too late in the execution, but I’ve found that
> > with an AbstractMavenLifecycleParticipant at least afterProjectsRead gets
> > called before artifact resolution. However, I can’t seem to affect the
> > server password in a way that allows artifact resolution to  succeed.
> > I’ve also tried overriding some default implementations, but I don’t see
> > the extension getting invoked (I see that Maven is aware of the extension,
> > but it doesn’t get used AFAICT).
> >
>

[ANN] Apache Maven JXR 3.4.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Apache 
Maven JXR version 3.4.0


This module generates browsable HTML pages from Java source code.

https://maven.apache.org/jxr/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-jxr-plugin
  3.4.0



Release Notes - Maven JXR - Version 3.4.0

** Dependency upgrade
* [JXR-190] - Upgrade commons-io:commons-io to 2.16.0
* [JXR-191] - Upgrade to Parent 42 and Maven 3.6.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Shared JAR 3.1.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Apache 
Maven Shared JAR, version 3.1.0.


https://maven.apache.org/shared/maven-shared-jar/


Release Notes - Apache Maven Shared JAR - Version 3.1.0

** New Feature
* [MSHARED-1256] - Add support for Multi-Release JARs

** Dependency upgrade
* [MSHARED-1354] - Upgrade parent POM to version 41
* [MSHARED-1376] - Upgrade commons-codec:commons-codec to 1.16.1
* [MSHARED-1377] - Upgrade org.apache.bcel:bcel from 6.7.0 to 6.8.2
* [MSHARED-1406] - Upgrade to Parent 42 and Maven 3.6.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Custom auth plugin/extension - how to?

[Tamás Cservenák]

Howdy,

What are you trying to do? You may go better if you implement custom
(resolver) transport maybe?

Thanks
T

On Mon, Jun 3, 2024, 22:22 David Grieve 
wrote:

> My questions are: Is this doable and, if so, how would one go about it?
>
> I’m trying to cobble together a plugin/extension that will either get an
> auth token for resolving an artifact before the artifact is resolved, or
> will get an auth token if the resolution returns a 401.
> The plugin route happens too late in the execution, but I’ve found that
> with an AbstractMavenLifecycleParticipant at least afterProjectsRead gets
> called before artifact resolution. However, I can’t seem to affect the
> server password in a way that allows artifact resolution to  succeed.
> I’ve also tried overriding some default implementations, but I don’t see
> the extension getting invoked (I see that Maven is aware of the extension,
> but it doesn’t get used AFAICT).
>

Custom auth plugin/extension - how to?

[David Grieve]

My questions are: Is this doable and, if so, how would one go about it?

I’m trying to cobble together a plugin/extension that will either get an auth 
token for resolving an artifact before the artifact is resolved, or will get an 
auth token if the resolution returns a 401.
The plugin route happens too late in the execution, but I’ve found that with an 
AbstractMavenLifecycleParticipant at least afterProjectsRead gets called before 
artifact resolution. However, I can’t seem to affect the server password in a 
way that allows artifact resolution to  succeed.
I’ve also tried overriding some default implementations, but I don’t see the 
extension getting invoked (I see that Maven is aware of the extension, but it 
doesn’t get used AFAICT).

[ANN] Maven Javadoc Plugin 3.7.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Javadoc Plugin, version 3.7.0.


This module generates browsable HTML pages from Java source code.

https://maven.apache.org/plugins/maven-javadoc-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-javadoc-plugin
  3.7.0



Release Notes - Maven Javadoc Plugin - Version 3.7.0

** Bug
* [MJAVADOC-793] - java.lang.NullPointerException: Cannot invoke 
"String.length()" because "text" is null


** Dependency upgrade
* [MJAVADOC-788] - Upgrade commons-io:commons-io to 2.16.0
* [MJAVADOC-789] - Upgrade 
org.codehaus.plexus:plexus-interactivity-api to 1.3

* [MJAVADOC-795] - Upgrade to Parent 42 and Maven 3.6.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Site Plugin 4.0.0-M15 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Site Plugin, version 4.0.0-M15.


https://maven.apache.org/plugins/maven-site-plugin/


Release Notes - Maven Site Plugin - Version 4.0.0-M15

** Dependency upgrade
* [MSITE-1008] - Upgrade to Parent 42 and Maven 3.6.3
* [MSITE-1009] - Upgrade plugins and components (in ITs)


Please also note for this new major version: 
https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Plugin Tools 3.13.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Apache 
Maven Plugin Tools, version 3.13.1.


https://maven.apache.org/plugin-tools/


Release Notes - Maven Plugin Tools - Version 3.13.1

** Task
* [MPLUGIN-526] - Clean up dependencies reported by 
dependencies:analyze



Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Transfer failed in an IPv6-only (+NAT64) environment

[Willy Manga]

On 31/05/2024 17:11, Tamás Cservenák wrote:

And one more hint:

See https://bugs.openjdk.org/browse/JDK-8311547


Regarding this issue, I don't know where is the best place to raise it 
but there are 3 contexts:

- IPv4-only
- dual-stack
- and ... IPv6-only
because this comment [1]seems to not consider the last case.


1. 
https://bugs.openjdk.org/browse/JDK-8311547?focusedId=14594731=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14594731


--
Willy Manga


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Transfer failed in an IPv6-only (+NAT64) environment

[Willy Manga]

Hi,

On 31/05/2024 17:11, Tamás Cservenák wrote:

And one more hint:

See https://bugs.openjdk.org/browse/JDK-8311547
and read about java.net.preferIPv6Addresses Java system property...

Also, try to invoke Maven as:
MAVEN_OPTS="-Djava.net.preferIPv6Addresses=true" mvn package -X


Thanks for the pointer. It solved the issue on transfer. I have a 
compilation failure now but I guess it's now related to missing packages 
on my side.


Regarding my version of Maven, I tend to stick to whatever the operating 
system have in the main repository. I will upgrade at least to debian 12 
; it comes with maven 3.8.7 [1] .


But once again, thank you.


1. https://packages.debian.org/bookworm/maven

--
Willy Manga


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Transfer failed in an IPv6-only (+NAT64) environment

[Tamás Cservenák]

And read this as well, Java is nicely covered:
https://www.reddit.com/r/ipv6/comments/scvuy0/what_devices_do_you_know_of_that_dont_support/

T

On Fri, May 31, 2024 at 3:11 PM Tamás Cservenák  wrote:

> And one more hint:
>
> See https://bugs.openjdk.org/browse/JDK-8311547
> and read about java.net.preferIPv6Addresses Java system property...
>
> Also, try to invoke Maven as:
> MAVEN_OPTS="-Djava.net.preferIPv6Addresses=true" mvn package -X
>
> (to pass to JVM to prefer IPv6 addresses)
>
> Thanks
> T
>
> On Fri, May 31, 2024 at 3:02 PM Tamás Cservenák 
> wrote:
>
>> Howdy,
>>
>> Unsure why, but:
>> - you use Maven 3.6.3 while the latest (bugfix) release is 3.9.7. A LOT
>> (especially transfer) related bugs were fixed down the road since 3.6.3.
>> - due 3.6.3 you use (probably old) Wagon transfer, that on the other hand
>> relies on (probably old) Apache HttpClient
>> - still, it seems Java TCP stack have issues to use your network as
>> stated in cause "java.net.SocketException: Network is unreachable (connect
>> failed)"
>> - you should verify is Java capable at all to use your network, as if it
>> cannot, Maven hardly can help here.
>>
>> Google for Java and IPv6 as there are a lot of SO and other hits that
>> showcases how to figure out (using Java simple code snippets) what may be
>> the problem.
>>
>> Thanks
>> T
>>
>> On Fri, May 31, 2024 at 2:37 PM Willy Manga  wrote:
>>
>>> Hi,
>>>
>>>
>>> I want to build guacamole-client as explained in the mainstream
>>> repository[0] but the transfer failed as you can see here[1].
>>>
>>> My environment:
>>> - maven 3.6.3-5 (running on debian 11)
>>> - IPv6-only with a NAT64 gateway in the network.
>>>
>>>
>>> Someone in the guacamole user mailing-list suggested it might be an
>>> issue with how either my network is setup or "some java incompatibilty"
>>> [2] .
>>>
>>> I don't see on my side what can be wrong with the network. I was able to
>>> retrieve manually build-helper-maven-plugin-3.2.0.pom using wget. But I
>>> don't know if during the execution of 'mvn package' something is pulling
>>> resource from a hard-coded address. If that's the case it can explained
>>> the failure.
>>>
>>> Any guidance appreciated.
>>>
>>> Thanks.
>>>
>>>
>>> 0. https://github.com/apache/guacamole-client
>>>
>>> 1. http://paste.debian.net/1318665/
>>>
>>> 2. https://lists.apache.org/thread/xh31qjn3fwv7llz3dtc31n0d5pks5jms
>>>
>>>
>>> --
>>> Willy Manga
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>

Re: Transfer failed in an IPv6-only (+NAT64) environment

[Tamás Cservenák]

And one more hint:

See https://bugs.openjdk.org/browse/JDK-8311547
and read about java.net.preferIPv6Addresses Java system property...

Also, try to invoke Maven as:
MAVEN_OPTS="-Djava.net.preferIPv6Addresses=true" mvn package -X

(to pass to JVM to prefer IPv6 addresses)

Thanks
T

On Fri, May 31, 2024 at 3:02 PM Tamás Cservenák  wrote:

> Howdy,
>
> Unsure why, but:
> - you use Maven 3.6.3 while the latest (bugfix) release is 3.9.7. A LOT
> (especially transfer) related bugs were fixed down the road since 3.6.3.
> - due 3.6.3 you use (probably old) Wagon transfer, that on the other hand
> relies on (probably old) Apache HttpClient
> - still, it seems Java TCP stack have issues to use your network as stated
> in cause "java.net.SocketException: Network is unreachable (connect failed)"
> - you should verify is Java capable at all to use your network, as if it
> cannot, Maven hardly can help here.
>
> Google for Java and IPv6 as there are a lot of SO and other hits that
> showcases how to figure out (using Java simple code snippets) what may be
> the problem.
>
> Thanks
> T
>
> On Fri, May 31, 2024 at 2:37 PM Willy Manga  wrote:
>
>> Hi,
>>
>>
>> I want to build guacamole-client as explained in the mainstream
>> repository[0] but the transfer failed as you can see here[1].
>>
>> My environment:
>> - maven 3.6.3-5 (running on debian 11)
>> - IPv6-only with a NAT64 gateway in the network.
>>
>>
>> Someone in the guacamole user mailing-list suggested it might be an
>> issue with how either my network is setup or "some java incompatibilty"
>> [2] .
>>
>> I don't see on my side what can be wrong with the network. I was able to
>> retrieve manually build-helper-maven-plugin-3.2.0.pom using wget. But I
>> don't know if during the execution of 'mvn package' something is pulling
>> resource from a hard-coded address. If that's the case it can explained
>> the failure.
>>
>> Any guidance appreciated.
>>
>> Thanks.
>>
>>
>> 0. https://github.com/apache/guacamole-client
>>
>> 1. http://paste.debian.net/1318665/
>>
>> 2. https://lists.apache.org/thread/xh31qjn3fwv7llz3dtc31n0d5pks5jms
>>
>>
>> --
>> Willy Manga
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: Transfer failed in an IPv6-only (+NAT64) environment

[Tamás Cservenák]

Howdy,

Unsure why, but:
- you use Maven 3.6.3 while the latest (bugfix) release is 3.9.7. A LOT
(especially transfer) related bugs were fixed down the road since 3.6.3.
- due 3.6.3 you use (probably old) Wagon transfer, that on the other hand
relies on (probably old) Apache HttpClient
- still, it seems Java TCP stack have issues to use your network as stated
in cause "java.net.SocketException: Network is unreachable (connect failed)"
- you should verify is Java capable at all to use your network, as if it
cannot, Maven hardly can help here.

Google for Java and IPv6 as there are a lot of SO and other hits that
showcases how to figure out (using Java simple code snippets) what may be
the problem.

Thanks
T

On Fri, May 31, 2024 at 2:37 PM Willy Manga  wrote:

> Hi,
>
>
> I want to build guacamole-client as explained in the mainstream
> repository[0] but the transfer failed as you can see here[1].
>
> My environment:
> - maven 3.6.3-5 (running on debian 11)
> - IPv6-only with a NAT64 gateway in the network.
>
>
> Someone in the guacamole user mailing-list suggested it might be an
> issue with how either my network is setup or "some java incompatibilty"
> [2] .
>
> I don't see on my side what can be wrong with the network. I was able to
> retrieve manually build-helper-maven-plugin-3.2.0.pom using wget. But I
> don't know if during the execution of 'mvn package' something is pulling
> resource from a hard-coded address. If that's the case it can explained
> the failure.
>
> Any guidance appreciated.
>
> Thanks.
>
>
> 0. https://github.com/apache/guacamole-client
>
> 1. http://paste.debian.net/1318665/
>
> 2. https://lists.apache.org/thread/xh31qjn3fwv7llz3dtc31n0d5pks5jms
>
>
> --
> Willy Manga
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Transfer failed in an IPv6-only (+NAT64) environment

[Willy Manga]

Hi,


I want to build guacamole-client as explained in the mainstream 
repository[0] but the transfer failed as you can see here[1].


My environment:
- maven 3.6.3-5 (running on debian 11)
- IPv6-only with a NAT64 gateway in the network.


Someone in the guacamole user mailing-list suggested it might be an 
issue with how either my network is setup or "some java incompatibilty" 
[2] .


I don't see on my side what can be wrong with the network. I was able to 
retrieve manually build-helper-maven-plugin-3.2.0.pom using wget. But I 
don't know if during the execution of 'mvn package' something is pulling 
resource from a hard-coded address. If that's the case it can explained 
the failure.


Any guidance appreciated.

Thanks.


0. https://github.com/apache/guacamole-client

1. http://paste.debian.net/1318665/

2. https://lists.apache.org/thread/xh31qjn3fwv7llz3dtc31n0d5pks5jms


--
Willy Manga

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Shade Plugin 3.6.0 Released

[Tamás Cservenák]

The Apache Maven team is pleased to announce the release of the Apache Maven
Shade Plugin, version 3.6.0

This plugin provides the capability to package the artifact in an uber-jar,
including its dependencies and to shade - i.e. rename - the packages of some
of the dependencies.

https://maven.apache.org/plugins/maven-shade-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-shade-plugin
  3.6.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-shade-plugin/download.cgi

Release Notes - Maven Shade Plugin - Version 3.6.0

** Bug
* [MSHADE-428] - Typo causes mysterious NPE in build
** New Feature
* [MSHADE-478] - Add ability to inject extra artifacts into shaded
output
** Task
* [MSHADE-473] - Drop legacy and superfluous deps:
maven-dependency-tree and commons-collections4
** Dependency upgrade
* [MSHADE-474] - Align dependencies with Maven 3 (as this is Maven3
plugin)
* [MSHADE-475] - Upgrade commons-io to 2.16.1
* [MSHADE-476] - Upgrade commons-compress to 1.26.2
* [MSHADE-477] - (test) Upgrade test dependencies

Have fun,
-The Apache Maven team

Re: Hmm ...

[Karl Heinz Marbaise]

Hi,


which Maven versions do you use? Which JDK versions do you use?

Which plugin versions do you use in your builds?

etc. There are missing so much information so I can not even guess what
might be a point?

Do you have tests running? How much? Have you measured the plain build
time? With or without the tests etc. ?

BTW: Which projects do you build ? Do you have example projects?

Kind regards
Karl Heinz Marbaise
On 28.05.24 15:35, Tommy Svensson wrote:

Performance problems

When I bought my Apple MacBook Pro M1 machine with 10 cores (real, not 
threaded) and 64 GB memory, I was able to build one of my multimodule projects 
in around 4 seconds! The project had 4 modules at the time.

I now build on Samsun external disk and it takes 29 seconds to build with 2 of the 
modules removed! So I first thought that it must be a difference in speed between 
external SSD and internal. "BlackMagic Disk Test" on Mac showed internal disk 
to be extremely must faster than external. Samsung: 791 apple internal: 4431. So I moved 
the code back to apples internal disk. That did however not make a difference!!!

But I have earlier build same project with twice the amount of code in it at 
around 4 seconds on internal disk! The speed test shows it is still as fast as 
it was before.

This makes me wonder if something has happened in maven that makes builds 
slower ? It is clearly not the disk speed that affects time it takes, so I can 
only assume Maven or Groovy! The latter is more complicated to verify, so I 
started with maven! This is not an accusation of any kind! Just wan't to se if 
I'm pretty much alone with this problem or not.

Best Regards,

Tommy Svensson
to...@natusoft.se






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Enforcer Plugin 3.5.0 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Enforcer Plugin, version 3.5.0

This plugin provides goals to control certain environmental
constraints such as Maven version,
JDK version and OS family along with many more built-in rules and user
created rules.

https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


 org.apache.maven.plugins
 maven-enforcer-plugin
 3.5.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.html

Release Notes - Maven Enforcer Plugin - Version 3.5.0

** Bug
* [MENFORCER-503] - requireOS cause NPE with Maven 3.9.7

** New Feature
* [MENFORCER-500] - New rule: Maven coordinates must match pattern

** Improvement
* [MENFORCER-490] - Properly declare dependencies
* [MENFORCER-494] - Allow banning dynamic versions before
computing the final dependency tree

** Dependency upgrade
* [MENFORCER-492] - Bump plexus-utils from 3.5.1 to 4.0.0 and
plexus-xml 3.0.0
* [MENFORCER-497] - Require Maven 3.6.3+
* [MENFORCER-498] - Upgrade parent POM to version 41
* [MENFORCER-501] - Update commons dependencies
* [MENFORCER-504] - Upgrade Parent to 42

Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Dependency Tree 3.3.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Dependency Tree version 3.3.0.


https://maven.apache.org/shared/maven-dependency-tree/


Release Notes - Maven Shared Components - Version 
maven-dependency-tree-3.3.0


** Bug
* [MSHARED-1286] - Display optional attribute for dependency in tree

** Dependency upgrade
* [MSHARED-1287] - Upgrade Parent to 41
* [MSHARED-1333] - Upgrade maven-shared-components to version 40
* [MSHARED-1400] - Upgrade maven-shared-components to version 42
* [MSHARED-1405] - Upgrade to Maven 3.6.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Hmm ...

[Tommy Svensson]

I've been told that I should just try earlier versions of maven and test! Of 
course!!

My excuse is that Stockholm have stolen the sun from Spain and our brains 
aren't used to this heat ... :-)

Tommy Svensson
to...@natusoft.se



Från: Tommy Svensson 
Svara: Maven Users List 
Datum: 28 maj 2024 at 15:37:30
Till: Maven Users List 
Ämne:  Hmm ...

Performance problems  

When I bought my Apple MacBook Pro M1 machine with 10 cores (real, not 
threaded) and 64 GB memory, I was able to build one of my multimodule projects 
in around 4 seconds! The project had 4 modules at the time.  

I now build on Samsun external disk and it takes 29 seconds to build with 2 of 
the modules removed! So I first thought that it must be a difference in speed 
between external SSD and internal. "BlackMagic Disk Test" on Mac showed 
internal disk to be extremely must faster than external. Samsung: 791 apple 
internal: 4431. So I moved the code back to apples internal disk. That did 
however not make a difference!!!  

But I have earlier build same project with twice the amount of code in it at 
around 4 seconds on internal disk! The speed test shows it is still as fast as 
it was before.   

This makes me wonder if something has happened in maven that makes builds 
slower ? It is clearly not the disk speed that affects time it takes, so I can 
only assume Maven or Groovy! The latter is more complicated to verify, so I 
started with maven! This is not an accusation of any kind! Just wan't to se if 
I'm pretty much alone with this problem or not.   

Best Regards,   

Tommy Svensson  
to...@natusoft.se  

Hmm ...

[Tommy Svensson]

Performance problems

When I bought my Apple MacBook Pro M1 machine with 10 cores (real, not 
threaded) and 64 GB memory, I was able to build one of my multimodule projects 
in around 4 seconds! The project had 4 modules at the time.

I now build on Samsun external disk and it takes 29 seconds to build with 2 of 
the modules removed! So I first thought that it must be a difference in speed 
between external SSD and internal. "BlackMagic Disk Test" on Mac showed 
internal disk to be extremely must faster than external. Samsung: 791 apple 
internal: 4431. So I moved the code back to apples internal disk. That did 
however not make a difference!!!

But I have earlier build same project with twice the amount of code in it at 
around 4 seconds on internal disk! The speed test shows it is still as fast as 
it was before. 

This makes me wonder if something has happened in maven that makes builds 
slower ? It is clearly not the disk speed that affects time it takes, so I can 
only assume Maven or Groovy! The latter is more complicated to verify, so I 
started with maven! This is not an accusation of any kind! Just wan't to se if 
I'm pretty much alone with this problem or not. 

Best Regards, 

Tommy Svensson
to...@natusoft.se

[ANN] Apache Maven Reporting Exec 2.0.0-M14 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Reporting Exec version 2.0.0-M14.


https://maven.apache.org/shared/maven-reporting-exec/


Release Notes - Maven Shared Components - Version 
maven-reporting-exec-2.0.0-M14


** Dependency upgrade
* [MSHARED-1392] - Upgrade to Parent 42 and Maven 3.6.3
* [MSHARED-1404] - Upgrade plugins and components (in ITs)


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Reporting Impl 4.0.0-M15 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Reporting Impl version 4.0.0-M15.


https://maven.apache.org/shared/maven-reporting-impl/


Release Notes - Maven Shared Components - Version 
maven-reporting-impl-4.0.0-M15


** Dependency upgrade
* [MSHARED-1392] - Upgrade to Parent 42 and Maven 3.6.3
* [MSHARED-1397] - Bump org.apache.maven:maven-archiver from 3.6.1 
to 3.6.2

* [MSHARED-1402] - Upgrade plugins and components (in ITs)


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org