plexus-cipher missing from transitive dependencies of maven-core 3.8.2

[Nils Breunese]

Hi,

I have a project that uses 
org.apache.maven.plugin-testing:maven-plugin-testing-harness:3.3.0 for testing 
a Maven plugin.

After upgrading the project’s Maven dependencies to Maven 3.8.2 I got this 
error message when running tests:


Error injecting: 
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher
java.lang.NoClassDefFoundError: 
org/sonatype/plexus/components/cipher/PlexusCipher  ... 117 more


PlexusCipher is a class in the plexus-cipher artifact, which is a transitive 
dependency of maven-core 3.8.1:


[INFO] org.example:plexus-cipher-mystery:jar:1.0-SNAPSHOT
[INFO] \- org.apache.maven:maven-core:jar:3.8.1:compile
[INFO]+- org.apache.maven:maven-model:jar:3.8.1:compile
[INFO]+- org.apache.maven:maven-settings:jar:3.8.1:compile
[INFO]+- org.apache.maven:maven-settings-builder:jar:3.8.1:compile
[INFO]|  +- org.codehaus.plexus:plexus-interpolation:jar:1.25:compile
[INFO]|  \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.4:compile
[INFO]| \- org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[INFO]+- org.apache.maven:maven-builder-support:jar:3.8.1:compile
(…snip…)


But plexus-cipher is not a transitive dependency of maven-core 3.8.2:


[INFO] org.example:plexus-cipher-mystery:jar:1.0-SNAPSHOT
[INFO] \- org.apache.maven:maven-core:jar:3.8.2:compile
[INFO]+- org.apache.maven:maven-model:jar:3.8.2:compile
[INFO]+- org.apache.maven:maven-settings:jar:3.8.2:compile
[INFO]+- org.apache.maven:maven-settings-builder:jar:3.8.2:compile
[INFO]|  +- org.codehaus.plexus:plexus-interpolation:jar:1.25:compile
[INFO]|  \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.4:compile
[INFO]+- org.apache.maven:maven-builder-support:jar:3.8.2:compile
(…snip…)


Both maven-core 3.8.1 and 3.8.2 have a transitive dependency on 
org.sonatype.plexus:plexus-sec-dispatcher:jar:1.4. The weird this is that when 
using maven-core 3.8.1 plexus-sec-dispatcher has a dependency on plexus-cipher, 
but when using maven-core 3.8.2 it doesn’t. How can this be?

The pom.xml of plexus-sec-dispatcher:1.4 
(https://search.maven.org/artifact/org.sonatype.plexus/plexus-sec-dispatcher/1.4/jar)
 indeed declares a dependency on plexus-cipher 1.4, but it’s not there when 
depending on maven-core 3.8.2.

How can this be? And is this intentional? Is there an exclusion somewhere?

Nils Breunese.

Re: plexus-cipher missing from transitive dependencies of maven-core 3.8.2

[Nils Breunese]

Michael Osipov  wrote:

> Please file an issue. I will add this to the known issues list then.

Thanks for confirming this regression, I’ve filed it as a bug here: 
https://issues.apache.org/jira/browse/MNG-7219

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

Re: Best practice to update dependency versions for *many* projects to the current version

[Nils Breunese]

Another option is creating an artifact of type ‘pom’ that consists of just a 
pom.xml with a  section and optionally properties for the 
versions (so they can easily be overridden when needed), and importing this BOM 
(bill of materials) artifact in your applications.

See spring-boot-dependencies for an example: 
https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.5.4/pom

You can use such an artifact as the parent of your applications (especially 
handy if you also want to centralize plugin configurations, etc.), or import 
its dependency management like this:


  

  com.example
  example-dependencies
  1.0.0
  pom
  import

  


  
com.example
example-artifact

  


See 
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
 for more information about BOM POMs.

Nils.

> Op 2 sep. 2021, om 16:52 heeft Delany  het 
> volgende geschreven:
> 
> Hi Bruno,
> 
> You can define a property in a project all projects inherit from
> 
> 
>  3.2.4
> 
> Then add a dependencyManagement section that sections the version
> 
>  
>
>  
>cglib
>cglib
>${dep.cglib.cglib}
> 
> And use this plugin to check for updates etc
> https://www.mojohaus.org/versions-maven-plugin/
> 
> Delany
> 
> On Thu, 2 Sept 2021 at 16:40, Bruno  wrote:
> 
>> I have been developing in Java almost from the beginning, but have not
>> used Maven for much more than a few personal test apps. I am now about
>> to migrate nearly 100 applications to Maven and I am a bit concerned
>> about how to manage dependency versions across that many projects in the
>> future.
>> 
>> For a single app it is simple, go into the POM, modify the version of
>> the dependency, then verify that nothing broke due to newly unsupported
>> methods and fix the issues.
>> 
>> But if you have a lot of applications, the above method becomes very
>> time consuming and manual.
>> 
>> QUESTION:  Is there a best practice (or perhaps tools that help) for how
>> to handle updating the dependency versions for that many applications?
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Can not use a snapshot version in parent

[Nils Breunese]

Hervé BOUTEMY  wrote:

> Looking at the log, I see "Could not find artifact com.x.commonlibrary:cl-
> parent:pom:1.5.39-20210922124845805-SNAPSHOT"
> 
> It seems you referenced parent POM as "1.5.39-20210922124845805-SNAPSHOT" 
> when:
> 1. you should not add the "-SNAPSHOT" suffix but "1.5.39-20210922124845805": 
> Maven detects that the suffix represents a SNAPSHOT 

I’d expect it the other way around. Use 1.5.39-SNAPSHOT in pom.xml and Maven 
will use the latest snapshot for that version. That’s the whole point of 
snapshot versions, right?

https://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version

Nils.

Re: Avoid illegal access error from sonatype repository

[Nils Breunese]

Manuel Dahmen  wrote:

> I don't understand why XStream library is loaded since I don't have this in
> my dependencies.
> 
> pom.xml:
> https://github.com/manuelddahmen/empty3/blob/android/pom.xml

I do see this dependency at 
https://github.com/manuelddahmen/empty3/blob/android/pom.xml#L308-L312



  com.thoughtworks.xstream
  xstream
  1.4.18



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

Re: Ambari build

[Nils Breunese]

Marc Hoppins  wrote:

> This is a stock ambari 2.7.6 build attempt on Ubuntu 18.04.  I am not a java 
> entity but I am interested in understanding how these tools operate with a 
> view to getting away from Cloudera. We currently run with CDH 6.3, the 
> free/express version and this leaves us stuck with Centos7, or Ubuntu18, both 
> of which are EOL, or fast approaching.

You won’t be getting any news stuff anymore, but CentOS 7 is scheduled to 
receive maintenance updates until 2024-06-30, so there's almost 2.5 years left: 
https://wiki.centos.org/About/Product 

Nils.

Re: SOLVED: Strange ClassCastException during maven install

[Nils Breunese]

Bruno Melloni  wrote:

> If I understood the explanation, it seems that the spring boot starter 
> (parent) defaults to slf4j and that the code above removes that support while 
> replacing it with log4j2.

I don’t know what your goals are for this library, but I do wonder if it’s a 
good idea to let a library depend on Spring Boot starters. I would expect that 
more gets pulled in than you actually want or need, as you’ve found. Spring 
Boot starters are just artifacts that depend on one ore more other artifacts 
and are generally meant to be used by applications. Libraries typically depend 
on one or more those ‘lower level’ artifacts directly to explicitly define what 
they depend on and not pull in too much.

I maintain an in-house framework based on Spring Boot myself and I’d recommend 
importing the spring-boot-dependencies BOM of the Spring Boot version you’re 
targeting with your library into your library’s  section. 
That will allow you to use any dependency managed by Spring Boot without having 
to specify its version.

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms

Nils.

P.S. I notice your old POM uses Log4J 2.15.0, which is vulnerable to the pretty 
serious Log4Shell vulnerabilities.

Re: SOLVED: Strange ClassCastException during maven install

[Nils Breunese]

eeding to install them.

I realize this is all maybe a bit too much information at once, and maybe I 
haven’t really answered your questions yet. If you can let us know more about 
what exactly you’re trying to achieve, we may be able to help you with more 
focused issues.

Nils.

> On 1/26/2022 5:26 AM, Nils Breunese wrote:
>> Bruno Melloni  wrote:
>> 
>>> If I understood the explanation, it seems that the spring boot starter 
>>> (parent) defaults to slf4j and that the code above removes that support 
>>> while replacing it with log4j2.
>> I don’t know what your goals are for this library, but I do wonder if it’s a 
>> good idea to let a library depend on Spring Boot starters. I would expect 
>> that more gets pulled in than you actually want or need, as you’ve found. 
>> Spring Boot starters are just artifacts that depend on one ore more other 
>> artifacts and are generally meant to be used by applications. Libraries 
>> typically depend on one or more those ‘lower level’ artifacts directly to 
>> explicitly define what they depend on and not pull in too much.
>> 
>> I maintain an in-house framework based on Spring Boot myself and I’d 
>> recommend importing the spring-boot-dependencies BOM of the Spring Boot 
>> version you’re targeting with your library into your library’s 
>>  section. That will allow you to use any dependency 
>> managed by Spring Boot without having to specify its version.
>> 
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
>> 
>> Nils.
>> 
>> P.S. I notice your old POM uses Log4J 2.15.0, which is vulnerable to the 
>> pretty serious Log4Shell vulnerabilities.


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

Re: Possible protocol error, handshake_error when using Maven

[Nils Breunese]

christopher.mil...@gd-ms.com wrote:

> Using Maven 3.5.4 on RHEL 8.1 with OpenJDK 1.8.
> 
> I've been using maven okay for awhile now and now I'm getting the following 
> error when running a pom.xml file.
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar (default-jar) on project 
> SOFTWARE_Build_Media: Execution default-jar of goal 
> org.apache.maven.plugins:maven-jar-plugin:2.4:jar failed: Plugin 
> org.apache.maven.plugins:maven-jar-plugin:2.4 or one of its dependencies 
> could not be resolved: Failed to collect dependencies at 
> org.apache.maven.plugins:maven-jar-plugin:jar:2.4 -> 
> org.apache.maven:maven-archiver:jar:2.5: Failed to read artifact descriptor 
> for org.apache.maven:maven-archiver:jar:2.5: Could not transfer artifact 
> org.apache.maven:maven-archiver:pom:2.5 from/to central 
> (https://repo.maven.apache.org/maven2): Received fatal alert: 
> handshake_failure -> [Help 1]
> 
> 
> If I add -X to the end of my mvn command, I see this error often:
> 
> Received fatal alert: handshake_failure
> 
> 
> Googling around, might be a TLS mismatch issue.  Is there anyway to tell and 
> correct it?
> 
> 
> I've tried to add the following tag to my settings.xml, 
> true and get the same error.

Just some things to try and some questions:

Can you reproduce this error when just fetching that dependency by running this 
command?

mvn dependency:get 
-Dartifact=org.apache.maven.plugins:maven-jar-plugin:2.4:jar

If this fails, does it work when you use Maven 3.8.4?

curl 
https://downloads.apache.org/maven/maven-3/3.8.4/binaries/apache-maven-3.8.4-bin.tar.gz
 | tar -xz
./apache-maven-3.8.4/bin/mvn dependency:get 
-Dartifact=org.apache.maven.plugins:maven-jar-plugin:2.4:jar

This works fine for me on macOS 12.2 with Maven 3.8.4 and Azul Zulu OpenJDK 
8u322.

According to sslscan repo.maven.apache.org only supports TLS 1.2 connections. 
If you are getting TLS handshake errors, then I suspect that something in your 
stack does not support TLS 1.2, or maybe there is an issue with the trusted CA 
certificates.

As far as I know Java 8 should support TLS 1.2. What OpenJDK distribution and 
version do you use according to 'java -version'?

Can you the POM file directly without Maven or Java?

curl 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom

Isn’t RHEL 8.1 also in need of an update? I believe RHEL 8.4 is current?

Nils.


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

Re: List of dependencies with Mavens Java API

[Nils Breunese]

Joel Moberg  wrote:

> I want to use Mavens java API to read dependencies (including transitive)
> in a project and retrieve class and source jars. I would like to use an
> instance of MavenProject because this class seems to have everything I
> need. MavenCli constructs this instance in some way but I find it too
> difficult to extend MavenCli or modify it to retrieve the MavenProject
> instance. I wish that MavenCli was written in such a way to make it easier
> to extend, with fewer private fields, classes and methods.
> Do you have any other idea of using the API to get what I want? I
> don't want to parse CLI text output.

I don’t have experience with this, but I think the effective model builder 
should be able to do this: 
https://maven.apache.org/ref/3.8.4/maven-model-builder/

If you want to download the class and source jars of dependencies and don’t 
necessarily need to do it via a Java API, you can also get those via the 
dependency:get goal provided by the Maven Dependencies plugin: 
https://maven.apache.org/plugins/maven-dependency-plugin/usage.html#dependency:get

What is your functional need exactly?

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

Re: Possible protocol error, handshake_error when using Maven

[Nils Breunese]

I’m not sure, but I suspect RHEL 8.1 might have some outdated CA certificates. 
I think that updating to the latest RHEL update (8.4?) might resolve this issue.

Nils.

> Op 31 jan. 2022, om 16:01 heeft christopher.mil...@gd-ms.com het volgende 
> geschreven:
> 
> 
> Here is the java output: 
> 
> $ java -version
> openjdk version "1.8.0_302"
> OpenJDK Runtime Environment (build 1.8.0_302-b08)
> OpenJDK 64-Bit Server VM (build 25.302-b08, mixed mode) 
> 
> $ echo JAVA_HOME
> /etc/alternatives/java_sdk_1.8.0_openjdk 
> 
> 
> I'm chatting with a few co-workers and they might be having issues with Maven 
> as well.  Have to dig into here more here. 
> 
> Thanks
> 
> 
> 
> 
> -Original Message-
> From: Karl Heinz Marbaise  
> Sent: Saturday, January 29, 2022 5:08 AM
> To: Maven Users List ; Miller, Christopher (NE) 
> 
> Subject: Re: Possible protocol error, handshake_error when using Maven
> 
> 
> External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
> click links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> Hi,
> 
> 
> can you please write which exact version of the JDK you are using?
> Furthermore the Maven version you are using a bit out of time...
> Simplest try would be to upgrade to most recent version of Maven...
> 
> 
> Kind regards
> Karl Heinz Marbaise
> On 28.01.22 18:08, christopher.mil...@gd-ms.com wrote:
>> 
>> 
>> Using Maven 3.5.4 on RHEL 8.1 with OpenJDK 1.8.
>> 
>> I've been using maven okay for awhile now and now I'm getting the following 
>> error when running a pom.xml file.
>> 
>> [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-jar-plugin:2.4:jar (default-jar) on project 
>> SOFTWARE_Build_Media: Execution default-jar of goal 
>> org.apache.maven.plugins:maven-jar-plugin:2.4:jar failed: Plugin 
>> org.apache.maven.plugins:maven-jar-plugin:2.4 or one of its dependencies 
>> could not be resolved: Failed to collect dependencies at 
>> org.apache.maven.plugins:maven-jar-plugin:jar:2.4 -> 
>> org.apache.maven:maven-archiver:jar:2.5: Failed to read artifact descriptor 
>> for org.apache.maven:maven-archiver:jar:2.5: Could not transfer artifact 
>> org.apache.maven:maven-archiver:pom:2.5 from/to central 
>> (https://repo.maven.apache.org/maven2): Received fatal alert: 
>> handshake_failure -> [Help 1]
>> 
>> 
>> If I add -X to the end of my mvn command, I see this error often:
>> 
>> Received fatal alert: handshake_failure
>> 
>> 
>> Googling around, might be a TLS mismatch issue.  Is there anyway to tell and 
>> correct it?
>> 
>> 
>> I've tried to add the following tag to my settings.xml, 
>> true and get the same error.
>> 
>> Thanks
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Possible protocol error, handshake_error when using Maven

[Nils Breunese]

christopher.mil...@gd-ms.com wrote:

> Yes, we have a local Nexus repo where I can use curl command to 
> upload/download without errors.


When you have issues it’s when Maven is trying to download something directly 
from repo.maven.apache.org? So you don’t use your Nexus instance as a proxy for 
Maven Central, right?

Your Nexus will use a different TLS certificate chain than 
repo.maven.apache.org, so not having the correct CA certificate for Maven 
Central could still be the issue.

Does this command work on your machine?

curl 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom

If so, does getting that URL from a simple Java program work on your machine?

Nils.

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

Re: aggregator project types

[Nils Breunese]

You can create a multi-module project, with one of the modules using its 
sibling modules as dependencies. The parent pom.xml would be of type ‘pom’ and 
contain the list of all modules in the project of type ‘jar’.

Nils.

> Op 31 jan. 2022 om 13:58 heeft Delany  het 
> volgende geschreven:
> 
> Can someone remind me why a type JAR project can't have modules?
> Is it unreasonable to expect a JAR project to produce its own JAR artifact,
> and then act as an aggregator of other projects?
> 
> Thanks,
> Delany

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

Re: Possible protocol error, handshake_error when using Maven

[Nils Breunese]

christopher.mil...@gd-ms.com wrote:

> I was able to curl that URL along with pulling that .pom file with the 
> following command: 
> 
> curl -o maven-archiver-2.5.pom  
> https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
> 
> So I'm still at a loss where I'm experiencing this issue currently.

Have you tried fetching that URL from a simple Java program to check whether 
your Java stack can access that URL?

——
❯ cat GetUrls.java 
import java.net.HttpURLConnection;
import java.net.URL;

class GetUrls {
public static void main(String[] args) throws Exception {
for (String arg : args) {
URL url = new URL(arg);
HttpURLConnection con = (HttpURLConnection) url.openConnection();
con.setRequestMethod("GET");
int status = con.getResponseCode();
System.out.println("[" + status + "] " + url);
}
}
}
❯ javac GetUrls.java
❯ java GetUrls 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
[200] 
https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.pom
——

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

zip file is empty

[Nils Breunese]

Hi,

I’ve been encountering Maven warnings like these for years from time to time:


WARN: zip file is empty: 
/Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
java.util.zip.ZipException: zip file is empty


I know that when I encounter this I can just delete the file and run Maven 
again and then it’ll generally download ok, but recently I’ve been getting 
questions from a lot of colleagues with this issue. I was wondering: would it 
make sense for Maven to assume that an empty JAR file was not downloaded 
correctly and try re-downloading it automatically?

Nils.

Re: zip file is empty

[Nils Breunese]

Jacques Etienne Beaudet  wrote:

> Maven repository is not safe when running multiple concurrent builds (not the 
> -T1C option). You need to use an external synchronization technique if you 
> need this. 
> https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html

I’ve asked my colleagues, but they weren’t doing parallel builds (-T or 
--threads).

Nils.

> Not sure of the implications of assuming an empty zip file means a failed 
> download, it seems reasonable to me but I'll let others chip in.
> On Feb 18, 2022, 7:43 AM -0500, Nils Breunese , wrote:
>> Hi,
>> 
>> I’ve been encountering Maven warnings like these for years from time to time:
>> 
>> 
>> WARN: zip file is empty: 
>> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
>> java.util.zip.ZipException: zip file is empty
>> 
>> 
>> I know that when I encounter this I can just delete the file and run Maven 
>> again and then it’ll generally download ok, but recently I’ve been getting 
>> questions from a lot of colleagues with this issue. I was wondering: would 
>> it make sense for Maven to assume that an empty JAR file was not downloaded 
>> correctly and try re-downloading it automatically?
>> 
>> Nils.


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

Re: zip file is empty

[Nils Breunese]

Ah, ok. But colleagues also report this happening in GitLab CI builds, which 
really only have one build running per Docker container.

Nils.

> Op 18 feb. 2022, om 18:05 heeft jebeau...@gmail.com het volgende geschreven:
> 
> I'm not talking about the -T option, I'm talking about running 2 builds in
> parallel, something like
> cd /some/repo1
> mvn clean verify &
> cd /some/repo2
> mvn clean verify &
> 
> It could also be your IDE auto building too, I've seen that happen.
> 
> 
> On Fri, Feb 18, 2022 at 11:13 AM Nils Breunese  wrote:
> 
>> Jacques Etienne Beaudet  wrote:
>> 
>>> Maven repository is not safe when running multiple concurrent builds
>> (not the -T1C option). You need to use an external synchronization
>> technique if you need this.
>> https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html
>> 
>> I’ve asked my colleagues, but they weren’t doing parallel builds (-T or
>> --threads).
>> 
>> Nils.
>> 
>>> Not sure of the implications of assuming an empty zip file means a
>> failed download, it seems reasonable to me but I'll let others chip in.
>>> On Feb 18, 2022, 7:43 AM -0500, Nils Breunese , wrote:
>>>> Hi,
>>>> 
>>>> I’ve been encountering Maven warnings like these for years from time to
>> time:
>>>> 
>>>> 
>>>> WARN: zip file is empty:
>> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
>>>> java.util.zip.ZipException: zip file is empty
>>>> 
>>>> 
>>>> I know that when I encounter this I can just delete the file and run
>> Maven again and then it’ll generally download ok, but recently I’ve been
>> getting questions from a lot of colleagues with this issue. I was
>> wondering: would it make sense for Maven to assume that an empty JAR file
>> was not downloaded correctly and try re-downloading it automatically?
>>>> 
>>>> Nils.
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: zip file is empty

[Nils Breunese]

Tamás Cservenák  wrote:

> Would be good to know
> - OS (from path I guess macOS)

Got recent reports from both macOS and Linux hosts.

> - Java

Mostly Azul Zulu OpenJDK, but probably also other OpenJDK-based distributions.

> - maven version (w/ any modding, if applicable)

Mostly 3.8.4, maybe also some older 3.x versions.

> - any extension present?

No.

The cause of these failed downloads could be a network issue in our company 
maybe, but since those can happen anywhere and any time, I’m interested if 
Maven could be made more resilient to network issues.

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

Re: zip file is empty

[Nils Breunese]

Bernd Eckenfels  wrote:

> First thing would be to determine if those are failed downloads or creates 
> (installed from local built). In both cases however failures should not 
> result in that. For downloads you have checksum checks and for build 
> artifacts they are copied from target/ (depending on the plugins used to 
> install them of course).
> 
> Is that a groupid and Version you built on that machine or are those external 
> artifacts?

The empty files are for artifacts available on our Artifactory server. The 
files are non-empty on the server and get downloaded ok after removing the 
local empty ones and running Maven again.

> Are there any remote.properties in the artifact directory in your Repo cache 
> dir?

I personally don’t have any in my ~/.m2/repository folder. What would having 
such a file mean?

> One possible cause could be process or OS crashes since maven does probably 
> not fdsync new files (before rename). But you probably would know if that 
> happens more often.

Yeah, there were no OS crashes.

Nils.

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

Re: zip file is empty

[Nils Breunese]

Tushar Kapila  wrote:

> Just out of curiosity which os are you using?

I run macOS myself, but I’ve also seen it happen on Linux. On StackOverflow I 
also find posts from people who encountered this issue on Windows, so it 
doesn’t seem to be an OS-specific issue.

> And are you doing parallel
> builds (more than one mvn command running at the same time?)

Maybe sometimes, but not generally and I’ve also seen this happening on GitLab 
CI builds, which run a single Maven build in a Docker container.

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

Re: zip file is empty

[Nils Breunese]

After reading the various responses to this thread with people recognizing this 
issue on various operating systems, I’ve opened an issue in the Maven issue 
tracker: https://issues.apache.org/jira/browse/MNG-7425

Nils.

> Op 18 feb. 2022, om 13:43 heeft Nils Breunese  het volgende 
> geschreven:
> 
> Hi,
> 
> I’ve been encountering Maven warnings like these for years from time to time:
> 
> 
> WARN: zip file is empty: 
> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> java.util.zip.ZipException: zip file is empty
> 
> 
> I know that when I encounter this I can just delete the file and run Maven 
> again and then it’ll generally download ok, but recently I’ve been getting 
> questions from a lot of colleagues with this issue. I was wondering: would it 
> make sense for Maven to assume that an empty JAR file was not downloaded 
> correctly and try re-downloading it automatically?
> 
> Nils.


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

Re: zip file is empty

[Nils Breunese]

Good news: Michael Osipov reports in the comments that this issue should go 
away with the fixes for concurrency issues that are coming up in Maven 3.9.0.

Nils.

> Op 28 feb. 2022, om 01:04 heeft Nils Breunese  het volgende 
> geschreven:
> 
> After reading the various responses to this thread with people recognizing 
> this issue on various operating systems, I’ve opened an issue in the Maven 
> issue tracker: https://issues.apache.org/jira/browse/MNG-7425
> 
> Nils.
> 
>> Op 18 feb. 2022, om 13:43 heeft Nils Breunese  het volgende 
>> geschreven:
>> 
>> Hi,
>> 
>> I’ve been encountering Maven warnings like these for years from time to time:
>> 
>> 
>> WARN: zip file is empty: 
>> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
>> java.util.zip.ZipException: zip file is empty
>> 
>> 
>> I know that when I encounter this I can just delete the file and run Maven 
>> again and then it’ll generally download ok, but recently I’ve been getting 
>> questions from a lot of colleagues with this issue. I was wondering: would 
>> it make sense for Maven to assume that an empty JAR file was not downloaded 
>> correctly and try re-downloading it automatically?
>> 
>> Nils.

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

Re: Plugin goal that will trigger "verify"

[Nils Breunese]

Steve Hannah  wrote:

> I'm trying to achieve better integration into VSCode with my project
> archetype. The way that the VSCode maven extension seems to prefer to work
> is for users to explicitly "run" a goal from a plugin of the project.
> 
> You can see the VSCode instructions for running a JavaFX app as an example
> here:
> https://code.visualstudio.com/docs/java/java-gui#_run-the-javafx-application
> 
> Basically, the user expands the Maven > Project > Plugins > JavaFX node,
> then right clicks the "javafx:run" goal, which is defined in the JavaFX
> maven plugin.
> 
> In the JavaFX example, that javafx:run goal actually spawns a new process
> that runs the app, which seems to break debugging.
> 
> With my own projects, I generally bind my "Run" goal to the "verify" phase
> so that running "mvn verify" will run my project.  This work OK in IntelliJ
> and NetBeans (although I need to do some contortions to make debugging
> work), but doesn't seem to mesh with VScode's way of doing things.
> 
> What I would like is to create a custom "run" goal in my plugin so that
> VSCode can run or debug this goal - and the goal should trigger everything
> up to the "verify" lifecycle - without having to spawn a new process.
> 
> I've been hitting walls in maven for years now, and I have a feeling that
> this is not possible.  Can someone either set me straight (i.e. inform me
> that it is possible), or confirm that, indeed, it is not possible?

The Maven build lifecycle consists of phases [0] and you can bind plugin goals 
to phases. As far as I know it doesn’t work the other way around, so you can’t 
make a plugin goal execute particular phases, which seems to be what you’re 
asking. It should be the other way around: you can associate a plugin goal with 
a phase and then when you execute that phase all previous phases will have been 
executed, and your plugin goal will be executed. I don’t use VSCode for Maven 
projects, but I hope it lets you trigger a phase instead of a goal? I know at 
least IntelliJ IDEA (which I use) supports this.

Nils.

[0] 
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Plugin goal that will trigger "verify"

[Nils Breunese]

Steve Hannah  wrote:

> VSCode does let you execute phases,
> but the "phase" model doesn't work well when you are working on
> desktop application.  You expect there to be an action to "run" the app and
> a separate action to "build" the app.

I don’t generally work on desktop application projects, but I don’t think it 
should be fundamentally different from working on web server applications.

The Maven build lifecycle, like the name suggests, is aimed at building 
projects. While a plugin goal might let you run something there is no specific 
build lifecycle phase for that. I generally let my IDE do the running, instead 
of involving Maven.

But you can pass both a phase and a plugin goal to Maven to run something, for 
instance like this:

./mvnw package spring-boot:run

Or like this:

./mvnw verify exec:java

I don’t know about VSCode, but an IDE should generally know when to build a 
project (via Maven or otherwise) when you run it. Running the built project can 
also be done without Maven, which is generally what I do when not using an IDE:

Build: ./mvnw verify
Run: java -jar target/my-app-1.0.0-SNAPSHOT.jar

>Neither of those are in the
> lifecycle.  What I typically do is bind the "run" to the lifecycle so that
> it will happen if I do `mvn verify`.

Maven let’s you do that of course, but semantically that is a bit of a hack, 
because the verify phase’s role is to ‘run any checks on results of integration 
tests to ensure quality criteria are met’ [0].

By the way, Maven let’s you define a default goal [1], which can also include 
phases and you could set to something like ‘verify exec:java’, so that when you 
run Maven without specifying any specific phases or goals, that will be 
executed. Maybe that would be helpful for you?

Nils.

[0]: 
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
[1] https://maven.apache.org/pom.html#Build_Element

Re: Plugin goal that will trigger "verify"

[Nils Breunese]

Thomas Broyer  wrote:

> Le mer. 9 mars 2022 à 23:48, Nils Breunese  a écrit :
> 
>> The Maven build lifecycle consists of phases [0] and you can bind plugin
>> goals to phases. As far as I know it doesn’t work the other way around, so
>> you can’t make a plugin goal execute particular phases, which seems to be
>> what you’re asking. It should be the other way around: you can associate a
>> plugin goal with a phase and then when you execute that phase all previous
>> phases will have been executed, and your plugin goal will be executed.
> 
> This is not entirely true. A mojo can be annotated with @Execute() to
> execute a lifecycle up to a given phase before the mojo itself is executed.
> That's the difference between jar:jar and jar:jar-no-fork for instance.

Ah, interesting, I didn’t know that. But that can only controlled by the Maven 
plugin developer then.

Nils.

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

Re: Dependency version change on dependency import

[Nils Breunese]

Rimvydas Vaidelis  wrote:

> I have a multi-module project and I want to create a bill of materials
> (BOM) module. BOM module contains dependencyManagement. My parent module
> imports BOM module. BOM module will be used in another project that is
> going to use my library. In development environment I would like to change
> version of one dependency. I tried to do that using a profile but it seems
> that maven does not activate the profile while performing import. Is it a
> normal behavior? Maybe you could recommend any other way to implement
> dependency version change in development environment.

I believe you can add a regular dependency entry for the artifact for which you 
want to override the version, like this:



  

  com.example
  example-bom
  1.0.0
  pom
  import


  com.example
  example-artifact-from-bom-i-want-to-override
  1.1.0-SNAPSHOT

  



  
com.example
example-artifact-managed-by-bom
  
  
com.example
example-artifact-from-bom-i-want-to-override
  



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

Re: Dependency version change on dependency import

[Nils Breunese]

Rimvydas Vaidelis  wrote:

> Thank you for the answer. I know that I can override the dependency version
> in pom that imports the bom module. I wanted to avoid duplicating of the
> dependency overriding in my library and in another project. However now I
> see that it is the only way to implement what I want.

What exactly do you need to duplicate? You could also specify the override 
version on the dependency directly, without putting it in dependencyManagement, 
but I personally only manage versions in dependencyManagement, because I often 
work on multi-module projects and consider that a good practice.

Another way to override a specific dependency would be to have a dedicated 
Maven property for it, so you’d only have to override that one.

I’m also kind of wondering why you have this use case. Generally when I import 
a BOM and need a new version of some dependency I just change the version of 
the whole BOM import, because that is supposed to be a consistent set of 
modules. Couldn’t you do that instead of overriding only one version from the 
BOM?

> Actually it was
> strange to me that maven does not respect active profiles on dependency
> import request. Maybe there is a reason why it is like that. It would be
> good if somebody could comment that. Is it by design or it is just
> implemented in this way?

When you use import you’re only importing  
as far as I know, so if there are  in the BOM those will not be 
imported.

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

Re: question java 1.7 support

[Nils Breunese]

Alexander Ushakov  wrote:

> 
>org.apache.maven.plugins
>maven-compiler-plugin
>3.1
>
>   1.17
>   1.17
>
> 
> 
> (…)
> 
> results with error
> 
> ```
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> (default-compile) on project streams.examples: Fatal error compiling:
> error: invalid target release: 1.17 -> [Help 1]
> ```
> 
> Java and Maven has been installed through SdkMan. Java 17.
> 
> Can someone, please, suggest the solution?

If you want to use Java 17, you should specify 17 instead of 1.17. Only 
releases up to and including Java 8 are specified as 1.x.

Nils.


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

Re: question java 1.7 support

[Nils Breunese]

Olivier Lamy  wrote:

> should be 1.7 not 1.17 ;)

No, 1.7 is for Java 7. For Java 17 it should be just 17.

Nils.

> On Sat, 26 Mar 2022 at 13:48, Alexander Ushakov <
> alexander.ushakov.em...@gmail.com> wrote:
> 
>> Hello!
>> 
>> I am trying to play with Apache Kafka and craft next pom.xml
>> 
>> ```xml
>> 
>> > xmlns="http://maven.apache.org/POM/4.0.0";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>>   4.0.0
>>   streams.examples
>>   streams.examples
>>   0.1
>>   jar
>>   Kafka Streams Demo Application
>>   
>>  UTF-8
>>  3.1.0
>>  1.7.7
>>  1.2.17
>>  1.17
>>   
>>   
>>  
>> apache.snapshots
>> Apache Development Snapshot Repository
>> 
>> https://repository.apache.org/content/repositories/snapshots/
>> 
>>false
>> 
>> 
>>true
>> 
>>  
>>   
>>   
>>  
>> 
>>org.apache.maven.plugins
>>maven-compiler-plugin
>>3.1
>>
>>   1.17
>>   1.17
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>   
>>   
>>  
>> org.apache.kafka
>> kafka-streams
>> ${kafka.version}
>>  
>>  
>> org.slf4j
>> slf4j-api
>> ${slf4j.version}
>>  
>>  
>> org.slf4j
>> slf4j-simple
>> ${slf4j.version}
>>  
>>   
>> 
>> ```
>> 
>> command
>> 
>> ```sh
>> mvn clean package
>> ```
>> 
>> results with error
>> 
>> ```
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
>> (default-compile) on project streams.examples: Fatal error compiling:
>> error: invalid target release: 1.17 -> [Help 1]
>> ```
>> 
>> Java and Maven has been installed through SdkMan. Java 17.
>> 
>> Can someone, please, suggest the solution?
>> 


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

Re: Determine Maven Dependencies after a build

[Nils Breunese]

Alexander Kriegisch  wrote:

> A personal note: I am trying to keep my hands off version ranges. I am
> not sure the assumed flexibility is worth the trouble of using it and
> running into the same issues as you. It also potentially creates a huge
> matrix of possible dependency version combinations which might or might
> not play nice with each other. How can you ensure to run your tests on
> all of them? Sometimes, there is a bug which affects you in 2.5.3, but
> not in 2.5.2, and quickly fixed in 2.5.4. Maybe you did or did not
> notice that it even exists. Then suddenly, someone uses the buggy
> version, and the software does not work despite green tests.

I would indeed also recommend to not use version ranges, and using a tool like 
Dependabot or Renovate to keep your dependencies up-to-date.

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

Re: Could not find artifact org.openjfx:javafx-web

[Nils Breunese]

Richard Schmidt  wrote:

> I am new to maven, NetBeans 13, and gluon and graalvm. I just created a a 
> gluon javafx project for desktop platform. I needed to add a dependency to 
> POM.XML file for org.openjfx, javafx-web. Most of the time I get the “could 
> not find artifact” javafx-web. Once in a while it works, but not for long. I 
> have tried to use other repositories to get it, but that fails also. Would 
> like to know how to get over this hump. Thanks!

I am not familiar with Gluon or JavaFX, but it seems org.openjfx:javafx-web is 
available from Maven Central [0]. I just tried adding it to one of my projects, 
and Maven downloaded the dependency just fine:


org.openjfx
javafx-web
17.0.2


I wonder what you mean with ’Once in a while it works, but not for long’. Once 
Maven has downloaded a dependency into your local Maven repository, it should 
find it for all next builds, because the dependency doesn’t need to be 
downloaded again.

Nils.

[0] https://search.maven.org/artifact/org.openjfx/javafx-web
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [ANN] Apache Maven Daemon 0.8.0 released

[Nils Breunese]

Guillaume Nodet  wrote:

> The Apache Maven team is pleased to announce release of the Apache Maven
> Daemon version 0.8.0.
> 
> Apache Maven Daemon is a daemon infrastructure for Maven with caching
> capabilities and a native client for a better and faster user experience.
> 
> This is the 1st release of the Apache Maven Daemon since its donation to
> the ASF.  This release embeds Apache Maven 3.8.5.
> 
> The release is available for download at:
>  https://downloads.apache.org/maven/mvnd/0.8.0/

There is no 0.8.0 release at https://github.com/apache/maven-mvnd/releases, 
although there is a 0.8.0 tag at https://github.com/apache/maven-mvnd/tags. 
Will releases no longer be available from GitHub from now on?

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

Re: MultiMaven project with by sharing dependencyManagement on parent pom

[Nils Breunese]

I don’t believe you can _include_ plugins and plugin dependencies, as far as I 
know you can only _inherit_ them from a parent. And an artifact can only have 
one parent.

There’s import for BOM artifacts, but that only ‘includes’ the 
entries from the BOM’s  section, and doesn’t do anything 
with plugins.

Nils.

> Op 6 jun. 2022, om 20:13 heeft Philipp Kraus  
> het volgende geschreven:
> 
> Hello,
> 
> I have got a MultiMaven project and within this project I have got two parent 
> poms. One of these parent inherits from an external parent. So I would like 
> to share all my build plugins and pluginManagemnt section, like
> 
> My-multi-maven-pom.xml
> 
>   my-plugins-and-pluginDependencies-pom.xml
> 
>   my-parent-pom.xml 
>   -> includes -> my-plugins-and-pluginDependencies-pom.xml
> 
>   my-external-parent-pom.xml 
>   -> inherits -> external-parent-pom.xml 
>   -> includes -> my-plugins-and-pluginDependencies-pom.xml
> 
> How is this possible?
> 
> Thanks a lot
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: How to properly override junit-platform and junit-jupiter in a parent pom

[Nils Breunese]

David Karr  wrote:

> We have a bunch of services running Spring Boot 2.3.12, which by default
> uses junit-platform 1.6.3 and junit-jupiter 5.6.3.
> 
> We are trying to instead use junit-platform 1.8.2 and junit-jupiter 5.8.2.
> All the artifacts and versions we need are in junit-bom-5.8.2.
> 
> We want to control this in our parent pom(s), as we have dozens of similar
> services all using the same parent pom.

Spring Boot dependencies for version 2.3.12.RELEASE 
(https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.3.12.RELEASE/pom)
 sets the junit-jupiter.version property to 5.6.3, but you can override that 
property in your own project.

I would consider upgrading to a more recent version of Spring Boot, because 
2.3.x reached end of OSS support on May 20, 2021 
(https://spring.io/projects/spring-boot#support). Spring Boot 2.7.0 
(https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.7.0/pom)
 comes with JUnit Jupiter 5.8.2 by default.

Nils.


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

Re: Maven fails to resolve version range for import

[Nils Breunese]

I can recommend not using version ranges, because they break build 
reproducibility. If you use a specific version and a tool like Dependabot or 
Renovate to create pull requests for updates, you’ll have a reproducible build 
without having to keep an eye out for updates yourself.

Nils.

> Op 27 jul. 2022, om 13:44 heeft Jacques Etienne Beaudet  
> het volgende geschreven:
> 
> Please see issue 
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-4463 and will 
> be resolved in maven 4 if I'm not mistaken.
> On Jul 27, 2022, 7:40 AM -0400, [Quipsy] Markus Karg , wrote:
>> I think I found a bug in Maven, but I am not sure. Maybe I am doing 
>> something wrong, so Maven Committers, please judge the following case:
>> 
>> A version range in a dependency like...
>> 
>> 
>> org.glassfish.jersey.core
>> jersey-server
>> [2.0.0, 3.0.0)
>> 
>> 
>> mvn dependency:tree
>> 
>> ...results in a correctly resolved output...
>> 
>> ...
>> +- org.glassfish.jersey.core:jersey-server:jar:3.0.0-RC2:compile
>> ...
>> 
>> But when instead using the same version range IN AN IMPORTED BOM, then...
>> 
>> 
>> 
>> org.glassfish.jersey
>> jersey-bom
>> [2.0.0, 3.0.0)
>> pom
>> import
>> 
>> 
>> 
>> 
>> org.glassfish.jersey.core
>> jersey-server
>> 
>> 
>> mvn dependency:tree
>> 
>> ...results in this error message as it was not resolved:
>> 
>> downloading from xxx: 
>> http://xxx:8081/content/groups/public/org/glassfish/jersey/jersey-bom/%5B2.0.0,%203.0.0)/jersey-bom-%5B2.0.0,%203.0.0).pom
>> 
>> Non-resolvable import POM: Could not find artifact 
>> org.glassfish.jersey:jersey-bom:pom:[2.0.0, 3.0.0)
>> 
>> In fact, calling curl -i 
>> http://nexus:8081/content/groups/public/org/glassfish/jersey/jersey-bom/%5B2.0.0,%203.0.0)/jersey-bom-%5B2.0.0,%203.0.0).pom
>>  tells us that such a URL does not exist: HTTP/1.1 400 Invalid repository 
>> path.
>> 
>> So am I doing or assuming something wrong here (e. g. possibly includes 
>> deliberately will not resolve version ranges) or is that simply a bug in 
>> Maven (which I should report in the issue tracker)?
>> 
>> Thanks!
>> -Markus


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

Re: Maven Wrapper: Using it with override settings.xml

[Nils Breunese]

I also use .mvn/maven.config with ‘--settings 
`. It works, but only when you invoke the mvnw 
script from the root directory of the project, otherwise the path to the 
settings.xml file will be wrong. That’s a slightly annoying limitation.

There’s an open issue to improve this: 
https://issues.apache.org/jira/browse/MNG-5659

Nils.

> Op 13 sep. 2022, om 12:00 heeft Slawomir Jaranowski  
> het volgende geschreven:
> 
> Hi,
> 
> You can create file: .mvn/maven.config [1] with content
> 
> --settings ./settings.xml
> 
> [1] https://maven.apache.org/configure.html#mvn-maven-config-file
> 
> wt., 13 wrz 2022 o 11:46 Delany  napisał(a):
> 
>> I used to place them in /.mvn/settings.xml but khmarbaise advised
>> against, so I inject the settings.xml file in via a Jenkins plugin
>> Delany
>> 
>> On Tue, 13 Sept 2022 at 11:33, Sverre Moe  wrote:
>> 
>>> But I still need to provide the settings.xml on all servers, and to all
>>> users from somewhere.
>>> Is there any way to repackage the maven distribution to include our
>>> settings.xml like we do for the Gradle distribution?
>>> 
>>> It would help if we could refer to an URL and not file. However then all
>>> who use the Maven Wrapper need to write a very long command line.
>>> ./mvnw --settings
>>> https://nexus.company.com:8443/repository/java/maven/settings.xml clean
>>> install
>>> 
>>> tir. 13. sep. 2022 kl. 10:16 skrev Mantas Gridinas >> :
>>> 
 You can override which settings file is used with --settings flag.
 
 On Tue, Sep 13, 2022, 11:08 Sverre Moe  wrote:
 
> I have been looking into the Maven Wrapper. We have mostly been using
> Gradle for new projects, but I was thinking of taking the Maven
>> Wrapper
 in
> use for our legacy projects that still use Maven.
> 
> With Gradle we can create a custom gradle distribution that has all
 common
> settings and properties needed by projects built by gradle.
> 
> How can we do the same with Maven?
> 
> Now we have the files settings.xml and settings-security.xml stored
>> in
> ~/.m2, which must be copied by all users into their own user home
> directory.
> 
> Running mvn wrapper:wrapper gave me this maven-wrapper.properties
> 
> distributionUrl=
> 
> 
 
>>> 
>> https://nexus.company.com:8443/repository/maven-public//org/apache/maven/apache-maven/3.8.4/apache-maven-3.8.4-bin.zip
> wrapperUrl=
> 
> 
 
>>> 
>> https://nexus.company.com:8443/repository/maven-public//org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1.jar
> 
> Even though the Maven Wrapper is downloaded from our Nexus, the
> dependencies are not, until I provide the settings.xml.
> 
 
>>> 
>> 
> 
> 
> -- 
> Sławomir Jaranowski


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

Re: Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Nils Breunese]

Hi Bruno,

It’s not completely clear to me what your issue is exactly. Is ’the old cached 
version from January’ that you refer to an artifact with a snapshot version or 
a release version? If it is a snapshot version, it depends on the update policy 
whether Maven will use a locally cached snapshot or whether it will try to 
fetch an update from the the configured repository. If there is no explicit 
update policy configured, I believe the default is to look for updates once a 
day. You can force Maven to update snapshots by using the -U (or 
--update-snapshots) flag. If your dependency is a release version, then there 
can be only one artifact for that version and if you have it cached locally, it 
should be identical to that version of the artifact on the repository server.

Maven 4 has not been released yet, are you sure you are (and should be) using 
that version? Version 3.8.6 is the current latest release [0].

To avoid having to manually update dependencies my team has a scheduled task to 
run Renovate [1] in our applications' CI pipelines to check for dependency 
updates. Renovate automatically creates a branch and a merge request whenever a 
dependency update is found. There are more tools like Renovate. For instance 
GitHub also provides Dependabot [2]. Maven Versions Plugin [3] can also be used 
to update dependencies.

Nils.

[0] https://maven.apache.org/download.cgi
[1] https://github.com/renovatebot/renovate
[2] https://docs.github.com/en/code-security/dependabot
[3] https://www.mojohaus.org/versions-maven-plugin/

> Op 23 sep. 2022, om 14:58 heeft Bruno  het volgende 
> geschreven:
> 
> I apologize for the length of this email, I could not think of a shorter way 
> to present the issue/questions that is clear enough.
> 
> ---
> 
> My environment involves the usual many open source dependencies (which I 
> control by specifying the versions to use in a master POM), but also a large 
> number of frequently changing internally built dependencies and a huge number 
> of applications that rely on these dependencies.
> 
> Changes on these internally built dependencies are carefully controlled so 
> that they are always backwards compatible.  In over a decade before we used 
> maven we had a single instance of these dependencies and we never - not once 
> - had a version conflict problem.
> 
> But the default mode for Maven is to update the version number even for a 
> tiny change and then to manually update the version of the dependency in 
> every single project that depends on it.  Since we have a lot of those, this 
> is a horribly error prone process leading to applications that crash because 
> they are using the wrong version of a dependency.  As an example... one of 
> our crashing applications that was built yesterday was found to contain a 
> dependency JAR from January!!! when it should have contained a JAR that was 
> also built yesterday.
> 
> Things that we tried:
> 
> - Builds and executions *INSIDE* of IntelliJ work beautifully. It always 
> finds the latest code and it always runs on the local integrated server 
> perfectly. _The problem happens in the JARs/WARs of applications placed into 
> the Maven local repository_.
> 
> - In IntelliJ we tried checking 
> Settings/Build,Execution,Deployment/BuildTools/Maven/"Always update 
> snapshots" and not change the version number between releases so that it 
> would include a fresh copy of the dependency during build, but even 
> *completely wiping out* the local repository (the only one in use at this 
> moment) it still used the old cached version from January.
> 
> - Next I tried to use the LATEST syntax in the POM.  But 
> LATEST was removed after Maven 2 and we are using Maven 4.
> 
> - Finally I tried to use [0.0.1, 0.0.999)-SNAPSHOT in the 
> hope of simply updating the version number of the dependency during 
> development/tests and only updating the formal dependency version to 1.0.0 at 
> release time but Maven rejected the syntax.  It is quite possible that the 
> syntax I used is incorrect, but sadly the documentation is not very clear and 
> provides no complete examples that I could inspect or duplicate.
> 
> *QUESTIONS*:
> 
> 1) Was one of the above methods supposed to work?  If yes, what did I do 
> wrong and how do I fix it?
> 
> 2) If none of the above methods is supported anymore (Maven 4), what method 
> should I be using?
> 
> 3) Is there any other tool - besides Maven - that I should be using for these 
> builds.


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

Re: Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Nils Breunese]

Bruno Melloni  wrote:

> First, you are right... I misread.  When I look at the maven plugins in 
> pluginManagement I see v2 and v3:  clean=3.1.0, compiler=3.8.1, 
> surefire=2.22.1, jar=3.0.2, install=2.5.2, deploy=2.8.2, site=3.7.1, 
> project-info-reports=3.0.0.  Still, it is > 2.0 so LATEST is no longer 
> supported as a version tag.

As far as I know there is no direct relation between Maven plugin versions and 
the version of Maven itself. If you add the -V flag to your build command the 
version of Maven itself will be printed. Or run Maven with just the -v if you 
want the Maven version without running a build.

> (1) IntelliJ is caching the JARs it uses for a project somewhere.  And giving 
> it the commands to reload dependencies or the POM fail if the version number 
> has not changed... since I am seeing a file from January.  Also, the IntelliJ 
> setting "Always update snapshots" fails as well.  This may be a Maven issue 
> or it might be a quirk of IntelliJ, my suspicion is that IntelliJ relied on 
> the old 2.x maven behavior for that setting.  Sadly I am not knowledgeable 
> enough to know.

And what happens when you build the apps using Maven directly instead of using 
IntelliJ?

> (2) Looking for an alternative all I found for 3.0 and above Maven was the 
> use of version ranges in the dependency entry of the app2 POM.  That would 
> require updating the version after even a tiny change in app1, but at least 
> it would not require updating the version in the the pom of the myriad of 
> "app2"s that we have, unless we wanted to.  I suspect this is what 
> versions-maven-plugin does but that I botched it when I tried to use it, as 
> its documentation is very confusing for a beginner and they don't provide a 
> single complete example of a POM that uses it.  The symptom was an error 
> popping up in the POM itself, long before trying to do a build.  I think the 
> error was either the "[0.0.1, 0.0.999)-SNAPSHOT" tag, or 
> my missing something in plugin management.

I don’t know if [0.0.1, 0.0.999)-SNAPSHOT is valid syntax, 
but if it is, then I would recommend not using it. (I generally would stay away 
from using version ranges in general, because it screws up reproducible 
builds.) As long as you’re using a snapshot version for the app1 dependency in 
app2 you should not need to bump the dependency version when making changes to 
app1.

Nils.

P.S. Maybe off-topic, but what is your use case for one app depending on 
another? I’d generally use a library dependency to share functionality between 
multiple apps.

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

Re: copy-resources plugin: can't replace readonly files

[Nils Breunese]

Burkhard Meier  wrote:

> If I had a Jira account, I would create a bug to get this fixed (…)

I’m not sure if you already requested a Jira account, but if not, please note 
that you can request a Jira account via the instructions on 
https://issues.apache.org/jira/

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

Re: MalformedInputException: Input length = 1

[Nils Breunese]

I’d say it’s pretty common to have binary files under src/main/resources 
actually. Images, movies, etc. for instance.

It’s also pretty common to commit Gradle Wrapper or Maven Wrapper JAR files, 
but in this case it looks like this Gradle Wrapper JAR is not used for building 
the codebase itself, but possibly for some other use case. I myself for 
instance maintain an application based on Spring Initializr, which also has 
these build tool wrapper JARs in its resources, because it can generate new 
projects with these files included.

I don’t know if the presence of this JAR makes sense in this case, but you 
indeed might want to exclude it from resource filtering.

Nils.

> Op 20 jan. 2023 om 17:22 heeft Karl Heinz Marbaise  het 
> volgende geschreven:
> 
> 
> Accidentially not included the list...
> 
> 
>  Forwarded Message 
> Subject: Re: MalformedInputException: Input length = 1
> Date: Fri, 20 Jan 2023 13:50:52 +0100
> From: Karl Heinz Marbaise 
> Reply-To: i...@soebes.de
> To: Tom Corcoran 
> 
> Hi,
>> On 18.01.23 17:23, Tom Corcoran wrote:
>> Hi,
>> 
>> I am working on upgrading my use of the openapi-generator-maven-plugin for
>> Spring Boot 3. My API gets generated and includes the expected pom.xml &
>> gradle elements (I only used the former).
>> 
>> Anyway then your plugin is used to copy 62 resourees,
>> maven-resources-plugin:3.3.0 and I get the message:
>> 
>>  [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-resources-plugin:3.3.0:resources
>> (default-resources) on project ABC: filtering
>>  ...\src\main\resources\v1\gradle\wrapper\gradle-wrapper.jar to
>> ...\target\classes\v1\gradle\wrapper\gradle-wrapper.jar failed with
>> MalformedInputException: Input length = 1
>> 
>> Any ideas are much appreciated!!
> 
> 
> Why is a JAR file in your src/main/resources directory? (binary file?)
> does not make sense nor can you filter a binary file correctly...
> 
> That is the reason.
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

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

Maven 3.9.0: Unable to parse maven.config file options: Unrecognized option: --settings .mvn/settings.xml

[Nils Breunese]

Hello,

I saw that Maven 3.9.0 was just released (congrats!) and I tried upgrading my 
projects. Sadly they failed with this error message:


Unable to parse maven.config file options: Unrecognised option: --settings 
.mvn/settings.xml


My projects indeed have a .mvn/maven.config file which contains (amongst other 
options) '--settings .mvn/settings.xml’ for project-specific settings.

When I remove that line from .mvn/maven.config and supply it on the command 
line (e.g. ./mvnw --settings .mvn/settings.xml) then it works fine, but I 
wonder why it doesn’t work when I put this option in .mvn/maven.config. Is this 
an intentional change in Maven 3.9.0, should I do this differently or is this 
maybe a bug?

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

Re: Maven 3.9.0: Unable to parse maven.config file options: Unrecognized option: --settings .mvn/settings.xml

[Nils Breunese]

Thanks for the link. When I replace this:

--errors
--show-version
-DinstallAtEnd=true
-DdeployAtEnd=true
--settings .mvn/settings.xml

with this:

--errors
--show-version
-DinstallAtEnd=true
-DdeployAtEnd=true
--settings
.mvn/settings.xml

in .mvn/maven.config then it indeed works, but I think this new format looks 
more confusing than the old one. And we have hundreds of projects that we’d 
need to make this change for…

Nils.

> Op 6 feb. 2023, om 13:32 heeft Tamás Cservenák  het 
> volgende geschreven:
> 
> Howdy Nils,
> 
> something similar was discussed here:
> https://lists.apache.org/thread/274g9dqj812rzs31q2xmj8tms0kv7wvk
> 
> Yes, there was a change that seems to have made it a bit stricter than it
> was before.
> 
> Michael?
> 
> HTH
> Tamas
> 
> On Mon, Feb 6, 2023 at 1:27 PM Nils Breunese  wrote:
> 
>> Hello,
>> 
>> I saw that Maven 3.9.0 was just released (congrats!) and I tried upgrading
>> my projects. Sadly they failed with this error message:
>> 
>> 
>> Unable to parse maven.config file options: Unrecognised option: --settings
>> .mvn/settings.xml
>> 
>> 
>> My projects indeed have a .mvn/maven.config file which contains (amongst
>> other options) '--settings .mvn/settings.xml’ for project-specific settings.
>> 
>> When I remove that line from .mvn/maven.config and supply it on the
>> command line (e.g. ./mvnw --settings .mvn/settings.xml) then it works fine,
>> but I wonder why it doesn’t work when I put this option in
>> .mvn/maven.config. Is this an intentional change in Maven 3.9.0, should I
>> do this differently or is this maybe a bug?
>> 
>> Nils.
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Maven 3.9.0: Unable to parse maven.config file options: Unrecognized option: --settings .mvn/settings.xml

[Nils Breunese]

Well, I’ve been using Maven for about 15 years and I didn’t know that you could 
use that format. The output of ‘mvn --help’ shows the options with a space 
instead of an equals sign, e.g.:

 -s,--settings Alternate path for the user
settings file

So, that’s why we’ve been using spaces.

Nils.

> Op 6 feb. 2023, om 13:47 heeft Delany  het 
> volgende geschreven:
> 
> Why would you do that though, and not
> --settings=.mvn/settings.xml
> 
> The intention is to disallow spaces. The fact that spaces are allowed on
> command line is unfortunate.
> Delany
> 
> On Mon, 6 Feb 2023 at 14:39, Nils Breunese  wrote:
> 
>> Thanks for the link. When I replace this:
>> 
>> --errors
>> --show-version
>> -DinstallAtEnd=true
>> -DdeployAtEnd=true
>> --settings .mvn/settings.xml
>> 
>> with this:
>> 
>> --errors
>> --show-version
>> -DinstallAtEnd=true
>> -DdeployAtEnd=true
>> --settings
>> .mvn/settings.xml
>> 
>> in .mvn/maven.config then it indeed works, but I think this new format
>> looks more confusing than the old one. And we have hundreds of projects
>> that we’d need to make this change for…
>> 
>> Nils.
>> 
>>> Op 6 feb. 2023, om 13:32 heeft Tamás Cservenák 
>> het volgende geschreven:
>>> 
>>> Howdy Nils,
>>> 
>>> something similar was discussed here:
>>> https://lists.apache.org/thread/274g9dqj812rzs31q2xmj8tms0kv7wvk
>>> 
>>> Yes, there was a change that seems to have made it a bit stricter than it
>>> was before.
>>> 
>>> Michael?
>>> 
>>> HTH
>>> Tamas
>>> 
>>> On Mon, Feb 6, 2023 at 1:27 PM Nils Breunese  wrote:
>>> 
>>>> Hello,
>>>> 
>>>> I saw that Maven 3.9.0 was just released (congrats!) and I tried
>> upgrading
>>>> my projects. Sadly they failed with this error message:
>>>> 
>>>> 
>>>> Unable to parse maven.config file options: Unrecognised option:
>> --settings
>>>> .mvn/settings.xml
>>>> 
>>>> 
>>>> My projects indeed have a .mvn/maven.config file which contains (amongst
>>>> other options) '--settings .mvn/settings.xml’ for project-specific
>> settings.
>>>> 
>>>> When I remove that line from .mvn/maven.config and supply it on the
>>>> command line (e.g. ./mvnw --settings .mvn/settings.xml) then it works
>> fine,
>>>> but I wonder why it doesn’t work when I put this option in
>>>> .mvn/maven.config. Is this an intentional change in Maven 3.9.0, should
>> I
>>>> do this differently or is this maybe a bug?
>>>> 
>>>> Nils.
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>> 
>>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: 3.9.0 not respecting proxy settings

[Nils Breunese]

Max Allan  wrote:

> I cannot easily set the values in a settings.xml or elsewhere because the
> proxy host is always different for each build and the proxy settings are
> only needed in CICD, so adding them to settings would break local developer
> builds.

You could have a CI-specific settings file in your project and provide that to 
Maven only in your CI pipeline like this:

$MAVEN --settings=.mvn/settings-ci.xml

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

Re: Plugin Developers: How to Determine Latest Maven API Versions

[Nils Breunese]

Excuse me if this has been previously discussed, but has using semantic 
versioning [0] ever been considered for versioning Maven itself? Maybe this 
could be adopted from Maven 4 onwards?

I’m a framework maintainer, and software that uses semantic versioning make 
users’ lives (including mine) so much easier, because a new release’s version 
number immediately makes it clear if backwards compatibility should be expected 
or not, if it brings new features (backwards compatible) or only fixes.

Software that introduces breaking changes in a minor or even patch version 
makes everyone’s lives unnecessarily difficult in my opinion.

Cheers, Nils.

[0] https://semver.org/

> Op 20 mrt. 2023 om 20:02 heeft Tamás Cservenák  het 
> volgende geschreven:
> 
> Hey Ryan,
> 
> (you might remember me, was committer on Enunciate project, while it was on
> Codehaus)
> 
> Let me start from the far end: When you say "Maven 3.x", you most probably
> mean (or you want to mean) Maven 3.2.5 and "onwards" (3.9.1 inclusive).
> Simply put, you should not strive to cover "all" from 3.0.x to 3.9.x, for
> simple (technical) reasons: Maven 3.0.x used org.sonatype package for
> resolver, Maven 3.1.x did not support Eclipse Sisu index usage, so the
> "most sane" Maven range to cover today is Maven 3.2.5-3.9.1. Actually, this
> is what we do at ASF Maven project as well, almost all "core" plugins are
> declared as compatible with this Maven range (with some rare exceptions).
> By targeting this range, you get rid of ugly problems like package renames,
> and various issues and shortcomings (like forced use of Plexus XML, etc).
> We also target Java 8 bytecode these days, we stopped supporting Java 7 and
> older platforms.
> 
> We, as contributors of the Maven project, simply have no resources to cover
> 10+ years (3.0 is 2010, 3.1 is 2013) of legacy, so this is the "best
> effort" we came up with. Or in other words, if someone MUST HAVE Maven
> support for some pre-3.2.5 version, they will have to either live with an
> older version of tooling (plugins) as well, that works with older Maven,
> or use a phonebook to order some pizza :)
> 
> What we typically do, is:
> a- declare "minimum runtime maven prerequisite" -- today this is for ASF
> Maven core plugins 3.2.5 (in maven-plugin POM this is
> project/prerequisite/maven element)
> b- declare "minimum maven dependencies" -- this is usually same as "minimum
> runtime maven prerequisite" (these are the maven dependencies you build
> against)
> c- declare "minimum built time maven prerequisite" -- this is required
> maven version to build the plugin (or project), this is good to keep up to
> date, ie. I would use 3.6.3 or even 3.8.8 or so, and can be enforced using
> enforcer (along with Java build time version and Java byte code versions).
> d- strive to use up to date maven-plugin-plugin (and related dependencies,
> like maven-plugin-annotations)
> 
> An example of this above (note: this is not ASF Maven Core plugin, but is a
> simple showcase as the plugin itself is simple. ASF Maven plugins have
> quite a deep POM parent-child hierarchy):
> a-
> https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L55-L57
> and
> https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L106
> b-
> https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L132-L155
> c-
> https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L132-L155
> and
> https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L233-L241
> d-
> https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L109
> 
> Moreover, all "maven dependencies" (those in groupID "org.apache.maven",
> part of Maven) should be in "provided" scope (as they are provided by Maven
> itself at plugin runtime. But a more recent maven-plugin-plugin (reason why
> is recommended) will direct you, and warn if some scope is off.
> 
> Finally, if you use plexus-utils, declare it explicitly, as starting with
> Maven 3.9.x plexus-utils is NOT auto-injected (provided) in the plugin
> classpath anymore.
> 
> Something similar I attempted to jot down here:
> https://cwiki.apache.org/confluence/display/MAVEN/Notes+For+Maven+3.9.x+Plugin+Developers
> 
> Another page, maybe not directly for you (targets Maven devs, but has
> useful information for plugin devs as well):
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup
> 
> All this above is for Maven plugins "in general", nothing in relation with
> "reporting", just a FYI.
> 
> Now, this above is "ideal case", if things get more hairy (ie. plugin
> reaches to some internals of Maven, maybe not even meant to be as Public
> API, this may usually cause some breakage), solution MAY be to lift lower
> end of "compatibility" from 3.2.5 to something like 3.6.3 or so, if
> possible
> 
>

Re: Maven slow

[Nils Breunese]

Tommy Svensson  wrote:

> I'm running Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) 
> That is what the latest version of IDEA gives me.

If you add Maven Wrapper [0] to your project, you can use any version of Maven 
you like, including the latest 3.9.1 release.

Nils.

[0] https://maven.apache.org/wrapper/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Multiple build profiles with 1 global

[Nils Breunese]

Kevin Huntly  wrote:

> I want to set up multiple build profiles for my app but I'm kindof
> confused. I have the idea of 1 global build profile that always gets used,
> plus smaller build profiles that get activated by the -P flag. Is this
> possible?

Anything that is not defined in a profile is always used.

Nils.

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

Re: Support for Java 9+

[Nils Breunese]

As far as I know this is only an issue on Java 9+ if you use a modulepath 
instead of a classpath. I can use these dependencies just fine on Java 11 and 
17.

Nils.

> Op 20 apr. 2023, om 18:50 heeft Rodrigo Bourbon 
>  het volgende geschreven:
> 
> Hi, I'm currently working with Java 11 and my project relies upon the
> maven-model  and
> maven-model-builder
>  artifacts.
> The problem is that both have the package org.apache.maven.model.merge, hence
> giving a split package issue when compiling with Java 9+. Is there any plan
> on being compatible with Java 9+ in the short term? What alternatives do
> you suggest?
> 
> Thanks in advance, Rodrigo.


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

Re: Support for Java 9+

[Nils Breunese]

As far as I know this dependency is not suitable for use with JMS. Using JMS is 
optional in Java 9+. You can use this dependency when using classpath instead 
of modulepath.

Nils.

> Op 21 apr. 2023, om 15:31 heeft Rodrigo Bourbon 
>  het volgende geschreven:
> 
> Hi Karl, indeed I'm talking about Java's Module System. In essence, I'm
> using maven-model because I need to analyze POM files.
> 
> Rodrigo.
> 
> On Fri, Apr 21, 2023 at 10:27 AM Karl Heinz Marbaise 
> wrote:
> 
>> Hi,
>> 
>> On 20.04.23 17:32, Rodrigo Bourbon wrote:
>>> Hi, I'm currently working with Java 11 and my project relies upon the
>>> maven-model 
>> and
>>> maven-model-builder
>>> 
>> artifacts.
>>> The problem is that both have the package org.apache.maven.model.merge,
>> hence
>>> giving a split package issue when compiling with Java 9+. Is there any
>> plan
>>> on being compatible with Java 9+ in the short term? What alternatives do
>>> you suggest?
>>> 
>>> Thanks in advance, Rodrigo.
>> Why does your project rely on maven-model? Creating a plugin or alike?
>> 
>> 
>> And what do you mean by Java 9+ compatible... ? Are you talking about
>> Java Module System?
>> 
>> Kind regards
>> Karl Heinz Marbaise
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Support for Java 9+

[Nils Breunese]

A lot of libraries are not suitable for use with modulepath applications yet, 
like this one. I think using Maven modules with classpath (and optionally some 
ArchUnit rules to enforce some architectural rules about what can access what) 
is also a fine way to modularize a project.

Nils.

> Op 21 apr. 2023, om 14:29 heeft Rodrigo Bourbon 
>  het volgende geschreven:
> 
> Hi Nils, you're right, the thing is that I'm working with the modulepath.
> I'm in the process of modularizing my project and I got stuck because of
> the mentioned issue.
> 
> Rodrigo.
> 
> On Thu, Apr 20, 2023 at 8:49 PM Nils Breunese  wrote:
> 
>> As far as I know this is only an issue on Java 9+ if you use a modulepath
>> instead of a classpath. I can use these dependencies just fine on Java 11
>> and 17.
>> 
>> Nils.
>> 
>>> Op 20 apr. 2023, om 18:50 heeft Rodrigo Bourbon 
>>> 
>> het volgende geschreven:
>>> 
>>> Hi, I'm currently working with Java 11 and my project relies upon the
>>> maven-model <
>> https://urldefense.com/v3/__https://github.com/apache/maven/tree/master/maven-model__;!!DCbAVzZNrAf4!DqxxLDpCuG6lh3Bizi0rlaUY25z2uCURWafVjcsNusPvoBDjqZ2wffqnuPCkhvUtXFpx4hdQ5uf-DwU$
>>> and
>>> maven-model-builder
>>> <
>> https://urldefense.com/v3/__https://github.com/apache/maven/tree/master/maven-model-builder__;!!DCbAVzZNrAf4!DqxxLDpCuG6lh3Bizi0rlaUY25z2uCURWafVjcsNusPvoBDjqZ2wffqnuPCkhvUtXFpx4hdQlfSJuTc$
>>> artifacts.
>>> The problem is that both have the package org.apache.maven.model.merge,
>> hence
>>> giving a split package issue when compiling with Java 9+. Is there any
>> plan
>>> on being compatible with Java 9+ in the short term? What alternatives do
>>> you suggest?
>>> 
>>> Thanks in advance, Rodrigo.
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Maven Artifact Resolver not seeing latest plugins on Maven Central on my machine

[Nils Breunese]

You can create a backup of the directory so you can restore it whenever you 
want for reproduction purposes.

You can also run Maven with an alternative local repository directory 
(-Dmaven.repo.local=/path/to/alternative/local/repo) to see if the issue is 
related to the state in your local Maven repository

Nils.

> Op 24 mei 2023 om 22:45 heeft Garret Wilson  het 
> volgende geschreven:
> 
> I hesitate to blindly rename the local directory, for fear of then not being 
> able to reduce this issue and get to the root of the problem.
> 
> Does no one on this list know what file or timestamp Maven Artifact Resolver 
> looks at to determine if it should go out to Maven Central to request the 
> latest versions rather than relying on the cached information?
> 
> Garret
> 
>> On 5/24/2023 10:40 AM, Delany wrote:
>> Try renaming `C:\Users\user\.m2\repository\`
>> Does the issue persist?
>> Delany
>> 
>>> On Wed, 24 May 2023, 18:04 Garret Wilson,  wrote:
>>> 
>>> I'm writing to this list on the advice of Andrzej Jarmoniuk on [Versions
>>> Maven Plugin Issue
>>> #959](https://github.com/mojohaus/versions/issues/959). I have also
>>> opened a [Stack Overflow question](https://stackoverflow.com/q/76307809)
>>> with a bounty, but so far there have been no responses.
>>> 
>>> In short Maven Artifact Resolver on my machine seems to be stuck at some
>>> previous point in time; it does not see the latest versions on Maven
>>> Central when I am requested updated plugin versions using Versions Maven
>>> Plugin. It shows that there are newer versions available, but the ones
>>> it shows are not the latest available. Before deleting my entire
>>> `C:\Users\user\.m2\repository\` directory tree I would prefer to know
>>> what is caused this scenario so that it won't happen again in the
>>> future. But at the moment I don't even understand what condition (e.g.
>>> incorrect timestamps or whatever) is currently causing this behavior.
>>> 
>>> I am using Maven 3.9.1 on Windows 10. I also use Eclipse EE 2023-03,
>>> which contains m2e (Eclipse's support for Maven). I start with [this
>>> `pom.xml`](
>>> https://github.com/globalmentor/globalmentor-root/blob/bce5bdbac7797b5b9114a72e5da2f4d76f3e24a7/pom.xml),
>>> 
>>> which uses `org.codehaus.mojo:versions-maven-plugin:2.12.0`, which in
>>> turn (I am told) uses Maven Artifact Resolver. (Note that I've tried the
>>> latest `org.codehaus.mojo:versions-maven-plugin:2.15.0` as well, with
>>> the same results. I'm using this POM because it's available online and
>>> does not contain any version ignores to cause confusion.)
>>> 
>>> I wanted to see what plugins were out of date, so I ran:
>>> 
>>> ```bash
>>> mvn versions:display-plugin-updates
>>> ```
>>> 
>>> It shows this:
>>> 
>>> ```
>>> [INFO] The following plugin updates are available:
>>> [INFO]   maven-failsafe-plugin .. 2.22.2 ->
>>> 3.0.0-M7
>>> [INFO]   maven-release-plugin  2.5.3 ->
>>> 3.0.0-M6
>>> [INFO]   maven-site-plugin .. 3.12.1 ->
>>> 4.0.0-M3
>>> [INFO]   maven-surefire-plugin .. 2.22.2 ->
>>> 3.0.0-M7
>>> [INFO]   org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 ->
>>> 3.0.5
>>> ```
>>> 
>>> However in Versions Maven Plugin Issue #959 (see link above), Andrzej
>>> Jarmoniuk ran the same command and came up with different answers. Here
>>> are two examples:
>>> 
>>> ```
>>> [INFO]   org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 ->
>>> 3.1.0
>>> ```
>>> 
>>> Note that my output is only showing v3.0.5 is available for
>>> `org.springframework.boot:spring-boot-maven-plugin`. Furthermore there
>>> are later versions available for some of the other plugins as well.
>>> 
>>> ```
>>> [INFO] com.akathist.maven.plugins.launch4j:launch4j-maven-plugin  2.1.3
>>> -> 2.4.1
>>> ```
>>> 
>>> My output doesn't even show
>>> `com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`; apparently
>>> it thinks thje v2.1.3 listed in the POM is the latest available!
>>> 
>>> It would appear that Maven Artifact Resolver is somehow "stuck" at some
>>> earlier point in time on my machine.
>>> 
>>> I ran Maven with the `-X` option, and here is part of the output related
>>> to `com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`:
>>> 
>>> ```
>>> …
>>> [DEBUG] Checking
>>> com.akathist.maven.plugins.launch4j:launch4j-maven-plugin for updates
>>> newer than 2.1.3
>>> [DEBUG] Could not find metadata
>>> com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml
>>> 
>>> in local (C:\Users\user\.m2\repository)
>>> [DEBUG] Skipped remote request for
>>> com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml,
>>> 
>>> locally cached metadata up-to-date
>>> [DEBUG]
>>> [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].version=2.1.3
>>> [DEBUG]
>>> 
>>> [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].artifactVersion=2.1.2
>>> [DEBUG]
>>> 
>>> [com.akat

Re: How to log in surefire which test classes are executed in which surefire thread?

[Nils Breunese]

I don’t have answers for your Surefire questions, but I wanted to mention that 
you can also tell JUnit 5.9.2 to execute tests in parallel: 
https://junit.org/junit5/docs/5.9.2/user-guide/index.html

Nils.

> Op 29 mei 2023 om 16:13 heeft Debraj Manna  het 
> volgende geschreven:
> 
> I updated by command like below
> 
> mvn test -Dorg.slf4j.simpleLogger.showThreadName=true
> 
> But I am observing that all my test classes are being executed in
> ThreadStreamConsumer
> 
> [ThreadedStreamConsumer] [INFO] Running
> com.spotnana.servicetests.profile.ProfileCreatePersonalUserTest
> ...
> [ThreadedStreamConsumer] [INFO] Running
> com.spotnana.servicetests.profile.PlanServiceTest
> 
> So can someone let me know if this is the correct way of logging the
> parallel execution identifier in maven output logs? If yes then what am I
> doing wrong which is causing all test classes to execute in a single thread?
> 
> Junit Version - 5.9.2
> 
> 
>> On Mon, May 29, 2023 at 6:53 PM Debraj Manna 
>> wrote:
>> 
>> I want to execute test classes concurrently in the same JVM. So my
>> surefire-plugin config looks like below
>> 
>> 
>>  org.apache.maven.plugins
>>  maven-surefire-plugin
>>  3.0.0-M7
>>  
>>
>>  $${surefire.forkNumber}
>>
>>
>>
>>  -Xms512m -Xmx${surefire.max.heap}
>>  -XX:MaxDirectMemorySize=${surefire.max.direct.memory}
>>  -XX:MaxMetaspaceSize=${surefire.metaspace.size}
>>  -XX:+HeapDumpOnOutOfMemoryError @{argLine}
>>
>>suitesAndClasses
>>false
>>${surefire.threadCount}
>>1
>>true
>>  
>> 
>> 
>> Can someone let me know if there is a way for me to know which test
>> classes are being executed in which surefire thread?
>> 

Re: Maven build error

[Nils Breunese]

Maven says it can’t find 
org.mule.tests.plugin:mule-tests-component-plugin:jar:mule-plugin:4.2.1 at 
https://repository-master.mulesoft.org/nexus/content/repositories/releases/

I can’t find it myself either, because there is no tests directory under 
https://repository-master.mulesoft.org/nexus/content/repositories/releases/org/mulesoft/

You’ll either need to make sure that this artifact is present in this 
repository, or configure an (additional) repository which contains this 
artifact.

Nils.

> Op 27 jul. 2023 om 19:21 heeft Willfin David  het 
> volgende geschreven:
> 
> 
> Hi,
>  
> Im using maven as part of my mulesoft anytime studio platform.
> When I run the below command from command prompt I get the error below.
>  
> Let me know how to resolve this error.
>  
> Command:
> maven -U clean install
>  
> Error:
> [ERROR] Failed to execute goal on project mule-connectivity-parent: Could not 
> resolve dependencies for project 
> com.mulesoft.connectors:mule-connectivity-parent:pom:3.3.1-RUNTIME.4.2.1: 
> Failed to collect dependencies at 
> org.mule.tests.plugin:mule-tests-component-plugin:jar:mule-plugin:4.2.1: 
> Failed to read artifact descriptor for 
> org.mule.tests.plugin:mule-tests-component-plugin:jar:mule-plugin:4.2.1: The 
> following artifacts could not be resolved: 
> org.mule.tests:mule-tests:pom:4.2.1 (absent): Could not find artifact 
> org.mule.tests:mule-tests:pom:4.2.1 in mule-releases 
> (https://repository-master.mulesoft.org/nexus/content/repositories/releases/) 
> -> [Help 1]
>  
>  
> 
>  
>  
> 
> ___
> The information contained in this communication is intended solely for the 
> use of the individual or entity to whom it is addressed and others authorized 
> to receive it. It may contain confidential or legally privileged information. 
> If you are not the intended recipient you are hereby notified that any 
> disclosure, copying, distribution or taking any action in reliance on the 
> contents of this information is strictly prohibited and may be unlawful. If 
> you have received this communication in error, please notify us immediately 
> by responding to this email and then delete it from your system. EY is 
> neither liable for the proper and complete transmission of the information 
> contained in this communication nor for any delay in its receipt.

Re: Confused about how to override a transient artifact version

[Nils Breunese]

David Karr  wrote:

> I've been struggling with trying to do this, along with trying to
> understand the output of "mvn dependency:tree" and the apparently
> functionally similar output in the "Dependency Hierarchy" view in Eclipse
> using the m2e plugin.  Although I can loosely see the hierarchical output
> from these, I find determining the actual details of where dependencies are
> coming from is very mystifying.

I recommend using the effective-pom goal of the maven-help-plugin [0] to get 
information about the effective POM that Maven ‘sees’, and if you enable 
verbose output there will be comments telling you where everything came from:

mvn help:effective-pom -Dverbose=true

I don’t use Eclipse, but in IntelliJ IDEA there are icons in the gutter of the 
editor that jump to the place where a versionless dependency‘s version is 
declared, which can be helpful too. I don’t know if there is a similar feature 
in Eclipse. (The Maven Helper plugin [1] for IntelliJ IDEA is also nice as an 
interactive and easier to read alternative to dependency:tree, including a 
filtering option.)

Nils.

[0] https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html
[1] https://plugins.jetbrains.com/plugin/7179-maven-helper

Re: elegant way to disable Nexus staging/deployment in child POMs

[Nils Breunese]

Garret Wilson  wrote:

> It is not a job for profiles. If I put it in a profile, a developer has to 
> only mistakenly use `-P nexus` or whatever the profile is, and our 
> super-secret million-dollar project gets published. I want it to be disabled 
> altogether.

Can I ask why you publish this root POM as a public artifact to Maven Central? 
If you’re using it to build super-secret million-dollar projects that shouldn’t 
be published publicly, it might be safer to publish this root POM to an 
internal Maven repository as well (as I suppose you already do for the projects 
that inherit from this root POM)?

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

Re: elegant way to disable Nexus staging/deployment in child POMs

[Nils Breunese]

Delany  wrote:

> In any case, what repository on the Internet is configured to allow
> anonymous uploads? The settings.xml must always be populated with 
> credentials for a deployment to take place.
> If you fear someone accidentally uploading artefacts to random repos then
> "you're doing it wrong". Credential in settings.xml and managed manually or
> someone other provisioning system = a good night sleep
> That's why I'm not a fan of https://issues.apache.org/jira/browse/MNG-5659

If you’re committing any file with credentials "you’re doing it wrong”. There 
are however also valid use cases for which project-specific settings are a very 
nice solution, so I’m happy it’s finally coming in Maven 4.

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

Re: elegant way to disable Nexus staging/deployment in child POMs

[Nils Breunese]

Delany  wrote:

> Oh hi Nils. Yeah well a compromise is reached. I would still support a ban
> on  tag in project-specific settings - more for enforcer.
> Its just about maintaining good abstractions. "User settings" what should
> that mean? Its basically the settings that a user doesn't want to commit.
> 
> You wanted "This is currently the only artifact repository that our build
> pipelines can access, but developers will sometimes want to build a project
> locally that requires other artifact repositories, e.g. a third-party
> GitHub project or an experimental Proof of Concept project which requires
> dependencies from a repository that hasn't been added to our in-company
> artifact repository yet. A global settings file that defaults to our
> private artifact repository would interfere with such local builds."
> 
> I just don't get the use case since I regularly make use of an alternative
> repository configured in my user settings when I test maven pre-releases
> 
>
>  stage
>  
>
>  stage
>
>  
>  
>
>  staging
>  Maven Staging
>  
> https://repository.apache.org/content/repositories/maven-${stage}/
>
>  
>  
>
>  staging-plugin
>  Maven Staging
>  
> https://repository.apache.org/content/repositories/maven-${stage}/
>
>  
>
>  
> 
> 
> When abstractions erode it becomes difficult to think. In this case though
> the idea of user settings was never a strong one.

We want our internal projects to be self-contained, so they work without a 
requirement for specific user or global Maven configuration, and we don’t want 
to require any non-internal projects to require any specific user or global 
Maven configuration either.

I’ve worked at companies we’re they said ‘your ~/.m2/settings.xml file needs to 
look exactly like this’, but then working with projects from outside the 
company (open source projects from GitHub for instance) became a hassle, 
because you need to temporarily change your user settings whenever you want to 
work with an external project on your machine. And of course there were always 
issues with people using an outdated or otherwise incorrect user settings file.

To get rid of those issues, we put `--settings=.mvn/settings.xml` in 
.mvn/maven.config in our internal projects to automatically apply the settings 
file included in the project (we have a Spring Initializr-based project 
generator which automatically adds these files in every project), which works, 
except that it doesn’t when Maven is not run from the root directory of a 
multi-module project. I understand project-specific settings should get rid of 
that limitation.

If anyone can think of a nicer solution than project-specific settings to 
accomplish such self-contained projects, I’d love to hear about it, because I 
agree that the project-specific settings feature also opens a new door to 
“you’re doing it wrong”.

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

Re: binding to phases programmatically

[Nils Breunese]

Justin Lee  wrote:

> I'm trying to write a plugin, it's probably an extension but whatever, that
> can arbitrarily bind functionality to different lifecycle phases based on
> the configuration in the pom file.  I'm curious 1) if this is even possible
> in maven, and 2) how I would go about that.

Maven includes this functionality via the  tag, you don’t need to 
do anything in the code of a Maven plugin for this: 
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#using-the-executions-tag

Example:


  

  org.example
  example-maven-plugin
  1.0.0
  

  example-execution1
  
example-goal
  
  test 

  

  

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

Re: binding to phases programmatically

[Nils Breunese]

Justin Lee  wrote:

> I understand that.  My question was doing that programmatically because my
> situation is rather dynamic and codify it in the pom is not what I need.

You wrote: "I'm trying to write a plugin (…) that can arbitrarily bind 
functionality to different lifecycle phases based on the configuration in the 
pom file."

Maven executes a plugin goal in a lifecycle phase, either its default phase, or 
the phase configured by a user. Users can bind plugin goals to any lifecycle 
phase using the  tag in the pom file. To me that sounded basically 
like what you described you wanted. Can you maybe explain your use case in some 
more detail to explain why it can’t use default’s mechanism for binding plugin 
goals to phases?

Note that a plugin cannot dynamically control in which phase it gets executed 
itself, because when it’s executed, it’s already executed in a particular 
phase. If you want to hook deeper into Maven’s behavior, you will indeed need 
to look into writing either a build extension or (even deeper) a core 
extension: https://maven.apache.org/guides/mini/guide-using-extensions.html

Nils.


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

Re: How to control ordering of transient dependencies?

[Nils Breunese]

If you wish to control the version of a transitive dependency, you can specify 
it in .

Nils.

> Op 29 aug. 2023 om 19:10 heeft David Karr  het 
> volgende geschreven:
> 
> I support a large number of SpringBoot services built with Maven.
> 
> I recently noticed that one of our transient dependencies has a conflict
> with another transient dependency, as it has several FQCNs that are
> identical to ones in the second artifact, but with different content.  In
> most of those services, the first artifact ended up in the classpath after
> the second artifact, so the "good" version of those classes was obtained
> from the second artifact.
> 
> In a couple of services, the order was reversed, causing fatal startup
> problems.
> 
> I thought perhaps that if I moved the "top-level" dependency that
> references the transient artifact to the bottom of the dependencies list in
> the pom.xml, it might control where that transient artifact ends up in the
> classpath. This unfortunately had no effect. It's possible this has an
> effect on the ordering of the "top-level" dependencies, but it didn't do
> anything for the transient dependencies.
> 
> I had thought that perhaps fixing this required changing the SpringBoot
> "classpath.idx" file that specifies the order that SpringBoot would load
> dependencies, so I created this issue:
> https://github.com/spring-projects/spring-boot/issues/37125
> 
> However, I think the responder is correct that the ordering in this file
> really should reflect the "Maven view" of dependency ordering.
> 
> In the particular case where this came up, I have resolved the problem the
> only way available to me, which is simply editing the problematic jar,
> removing the FQCNs that are duplicates, and creating a new artifact that
> services will use instead of the original jar. This is obviously a hack,
> and might not be possible in other situations.

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

Re: Maven Plugin error

[Nils Breunese]

Hi Manas,

Why do you believe that version 3.2.5 of this plugin exists? There is no 
version 3.2.5 of this plugin at 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
 and the archive site on the Maven Compiler Plugin download page 
(https://maven.apache.org/plugins/maven-compiler-plugin/download.cgi) also 
doesn’t list version 3.2.5.

Currently the latest version of this plugin is 3.11.0.

Nils.

> Op 28 aug. 2023, om 11:19 heeft Manas Chatterjee  het 
> volgende geschreven:
> 
> Hello All,
> I am using JDK version 1.8 in Red Hat  Developer studio.
> 
> While trying to Maven Build the following error is encountered.
> 
> *[ERROR] Plugin org.apache.maven.plugins:maven-compiler-plugin:3.2.5 or one
> of its dependencies could not be resolved: Failure to find
> org.apache.maven.plugins:maven-compiler-plugin:jar:3.2.5 in
> https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted
> until the update interval of central has elapsed or updates are forced ->
> [Help 1][ERROR]*
> 
> Please suggest possible troubleshooting.
> 
> Please find snippet of the pom.xml file below.
>   
> org.apache.maven.plugins
> maven-compiler-plugin
> 
> 3.2.5
> 
> ${jdk.version}
> ${jdk.version}
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-shade-plugin
> 
> 3.5.0
> 
> 
> 
> package
> 
> shade
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Please let me know if any additional details are required.
> 
> Regards,
> Manas


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

Re: Maven wrapper and sha256

[Nils Breunese]

Hi Alexis,

I don’t know if SHA-256 hashes are published anywhere, but after verifying the 
other hashes that are published on Maven Central, you could calculate the 
SHA-256 hashes yourself. (I’m sorry if I’m being Captain Obvious here.)

For the Maven distribution:

❯ shasum -a 256 
~/.m2/wrapper/dists/apache-maven-3.9.4-bin/*/apache-maven-3.9.4-bin.zip | awk 
‘{ print $1 }'
e896b60329a71b719d77bb4388b251a50aebcd73c62f69d510c858ce360afe0f

And for the Maven Wrapper JAR in your project:

❯ shasum -a 256 .mvn/wrapper/maven-wrapper.jar | awk '{ print $1 }'
e63a53cfb9c4d291ebe3c2b0edacb7622bbc480326beaa5a0456e412f52f066a

But yes, I agree it would be nicer if Maven Central and/or release notes would 
contain the SHA-256 hashes for use with this feature. Maybe open a request 
ticket for that 
(https://issues.apache.org/jira/secure/CreateIssue!default.jspa)?

Nils.

> Op 14 sep. 2023, om 16:29 heeft Alexis Tual  het volgende 
> geschreven:
> 
> Hi,
> 
> I noticed the Maven wrapper supports setting the sha256 for both the
> distributions and the wrapper jar:
> https://maven.apache.org/wrapper/#checksum-verification-of-downloaded-binaries
> .
> However I could not find those checksums in
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/ nor
> https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper.
> Where are they located?
> 
> Thanks for your help!
> 
> -- 
> 
> Alexis Tual

Re: Feedback sought

[Nils Breunese]

Joseph Kesselman  wrote:

> Re "IDE droppings"... My experience is that they can actually be useful in 
> expressing things like preferred code formatting style in 
> importable/executable form. (I'd rather have a standard cross-editor way if 
> representing that, but I don't know of one.)

You could take a look at EditorConfig: https://editorconfig.org/

Nils.

Re: Configuring plugins by composition rather than inheritance

[Nils Breunese]

This only imports Spring Boot dependencyManagement, and it looks like the 
thread starter would also like access to the plugins configured by 
spring-boot-parent. He’d have to duplicate Spring Boot's plugin configuration 
in his own project.

Nils.

> Op 5 dec 2023, om 15:11 heeft Francois Marot  het 
> volgende geschreven:
> 
> For the record, Spring Boot has no hard requirement of using a 'parent'
> pom. It is just a bit simpler and in most of the examples online.
> But you can simply set the scope import in your dependencyManagement. This
> works.
> 
> 
> 
> 
> 
> org.springframework.boot
> 
> spring-boot-dependencies
> 
> ${spring.boot.version}
> 
> pom
> 
> import
> 
> 
> 
> 
> Hope it helps
> 
> 
> 
> Le mar. 5 déc. 2023 à 12:51, Bernd Eckenfels  a
> écrit :
> 
>> Hello,
>> 
>> I think that’s a long-standing restriction of mavens Pom-model, not sure
>> it can easily be solved. Spring boot (and other frameworks) did not make
>> the situation easier with their parent requirement (but then again there is
>> not much alternatives).
>> 
>> From my experience it seems a good idea to get away from a strict „simple
>> company root“ requirement. (Due to release cycles it doesn’t do much for
>> unifying build jobs anyway).
>> 
>> Maven could improve with importing build/plugin sections like BOMs. I
>> haven’t seen much talk about that in recent 4.0 discussions,
>> 
>> Having said that a consumer Pom goes a good distance to make the parents
>> less relevant. (Especially licensing/orga matters)
>> 
>> Gruß
>> Bernd
>> 
>> Mantas Gridinas wrote on 5. Dec 2023 09:17 (GMT +01:00):
>> 
>>> In my current project i'm working we already have a parent POM that I
>>> should be inheriting from, but when trying to integrate the spring boot I
>>> come into an issue that I should inherit their super pom instead of using
>>> our own. For dependencies its pretty simple - you use the import scope,
>>> but
>>> what about plugins? I'm seeing some stackoverflow posts about the sameish
>>> issue from 11 years ago that the suggestion was to use tiles plugin. Was
>>> there any movement regarding this in the mean time?
>>> 
>>> As a workaround I currently have a dedicated springboot runtime module
>>> that
>>> includes a single entry point with respective annotations to start the
>>> application, and it directly inherits the spring boot super pom while
>>> importing our dependencies via the depencendy management block but having
>>> a
>>> submodule not inherit a parent module feels weird
>>> 
>> 
>> 
>> Gruß
>> Bernd
>> —
>> https://bernd.eckenfels.net
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Excluding artifact from project-info-reports dependency report

[Nils Breunese]

Can’t these resources be packaged in plain JARs and added as a regular 
dependency to the applications that require them, instead of using WAR overlays?

Nils.

> Op 19 dec 2023, om 06:53 heeft Mark Eggers  
> het volgende geschreven:
> 
> I have several artifacts that consist of WAR archives with no server 
> component.
> 
> In other words, there are only HTML, CSS, JS, JSP, images, fonts, etc.files 
> in these artifacts. There are no servlets, listeners, POJOs, resources, etc. 
> in these artifacts.
> 
> These artifacts are used as overlays in other projects to keep common 
> components managed.
> 
> When a dependency report is run using these artifacts, there is an error 
> along the lines of:
> 
> [ERROR] Artifact groupId:artifactId:war:version caused IOException:
> 
> [FILE_LOCATION]/classes  (The system cannot find the file specified)
> 
> -- stack trace --
> 
> Well this is obvious, since the WAR artifacts used as an overlay have no 
> WEB-INF/classes directories.
> 
> Is there a way to exclude these artifacts  from dependency checking for 
> projects that consume them? Or do I just live with the error messages in 
> site:site (the site builds correctly).
> 
> I'm using maven-project-info-reports-plugin 3.5.0 with a variety of Maven 
> versions (3.6.3, 3.9.6), and a variety of JDKs (8, 11, 17).
> 
> Any ideas would be greatly appreciated.
> 
> Thanks in advance,
> 
> Mark
> /mde/
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Releasing a multi-module project to Maven Central?

[Nils Breunese]

Maybe the BuildPlan Maven Plugin [0] can provide interesting insights?

Nils.

[0] https://www.mojohaus.org/buildplan-maven-plugin/

> Op 21 dec 2023, om 17:46 heeft Laird Nelson  het volgende 
> geschreven:
> 
> Thanks. I'll take whatever help I can get right now.
> 
> I've tried the jar goal and the jar-no-fork goal. Somehow the goal always
> runs multiple times. It is difficult to tell what is causing the rebuild.
> 
> (The javadoc plugin doesn't have a jar goal that doesn't fork, as far as I
> can tell. But also as far as I can tell even when forking it doesn't invoke
> the package phase, so the source plugin goal doesn't get kicked off by it
> again.)
> 
> Yes, I've read the publishing guide (and have released dozens of projects
> to Maven Central in the past using nothing more complicated than the
> recommended maven-release-plugin recipes). I don't remember, however, the
> last time I tried it with a multi-module project.
> 
> I'm beginning to suspect something about the Nexus staging plugin and its
> interaction with multi-module projects. It does want to do the actual
> deploy step at the very end of the project, and I just now noticed that I'm
> getting some strange log output. The reactor messages about which project
> is building contain strange counts.
> 
> For example, I have a grand total of four modules: the parent/aggregator,
> and three children. So as the parent is building, you see "[1/4]" (for
> example) in the logs. At the end of the Nexus-staging-plugin-managed
> deployment step, you see things like "[7/4]" which suggests to me something
> is going on deep in the reactor somewhere.
> 
> L
> 
> On Thu, Dec 21, 2023 at 12:04 AM Thomas Broyer  wrote:
> 
>> Shouldn't you use the jar-no-fork *goal* of the maven-source-plugin? Using
>> that value as execution id does nothing special.
>> 
>> BTW, did you read https://central.sonatype.org/publish/publish-maven/ ?
>> 
>> (No idea if any of this would solve your problem though)
>> 
>> Le jeu. 21 déc. 2023, 03:15, Laird Nelson  a écrit :
>> 
>>> On Wed, Dec 20, 2023 at 5:45 PM Laird Nelson  wrote:
>>> 
 That is, when I tell the maven-release-plugin to activate the
>>> "deployment"
 profile (via the releaseProfiles user property), I am told that the
>>> source
 plugin has been invoked twice, and the build fails.
 
>>> 
>>> I think this is because the maven-javadoc-plugin's jar goal invokes the
>>> lifecycle, which of course contains the maven-source-plugin's jar-no-fork
>>> goal, which attaches the source jar. How would I make this work?
>>> 
>>> Best,
>>> Laird
>>> 
 
>>> 
>> 


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

Re: Looking for an actively maintained (and working) docker maven plugin

[Nils Breunese]

Fabric8’s docker-maven-plugin works for my projects on macOS with Rancher 
Desktop providing Docker.

The GitHub issue you reported seems to be specifically related to the docker 
command being run by docker-maven-plugin not being supported by the docker 
binary on your system. (docker-maven-plugin calls the docker CLI client, it 
doesn’t contain a Java implementation of the Docker client.)

Nils.

> Op 27 dec 2023, om 09:15 heeft Steinar Bang  het volgende 
> geschreven:
> 
> I recently discovered that the docker-maven-plugin I had been using was
> archived on March 21 2022 and had the last code update on Januar 15 2020:
> https://github.com/spotify/docker-maven-plugin
> 
> The first thing I did was google and this one came up first, and seems
> actively maintained:
> https://github.com/fabric8io/docker-maven-plugin
> 
> However that plugin didn't work for me:
> https://github.com/fabric8io/docker-maven-plugin/issues/1739
> 
> Does anyone know of a maintained and working for them (preferrably on an
> amd64 debian/ubuntu computer) docker maven plugin?
> 
> What I'm looking for is something that
> 1. Reads a Docker file and performs the operations in that docker file,
>which for me, are:
>a. Fetch an image from docker hub
>b. Replace one file in the image
>c. Add one file to the image
> 
> (My images are based around the apache karaf official image and operate
> with maven provisioning of their applications. I let karaf pull the
> LATEST of whatever is deployed to maven central and whatever so I don't
> have to update the images when the application updates. But now I've run
> into the image I built with being incompatible with the OSGi version
> currently used (and probably also the java version, though it doesn't
> fail on that) so I need a new image buit 
> https://github.com/steinarb/sonar-collector/issues/5 )
> 
> Thanks!
> 
> - Steinar
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: How to pass java.library.path to mvn exec?

[Nils Breunese]

Hi Neil,

java.library.path is a system property. The Exec Maven Plugin documentation for 
exec:java and system properties is here: 
https://www.mojohaus.org/exec-maven-plugin/java-mojo.html#systemProperties

Nils.

> Op 5 jan 2024, om 17:40 heeft Neil Aggarwal  het 
> volgende geschreven:
> 
> Hello:
> 
> 
> 
> I am trying to pass java.library.path to a mvn exec command.
> 
> 
> 
> Here is what I tried:
> 
> mvn exec:java -Dexec.mainClass=com.fiscalassets.tax.PrintForm1098s
> -Dexec.args=application.properties.FiscalAssets
> -Djava.library.path=C:\OneDrive\Dev\Jacob
> 
> 
> 
> But, I get an error:
> 
> [ERROR] Failed to execute goal
> org.codehaus.mojo:exec-maven-plugin:3.1.0:java (default-cli) on project
> FAIntegration:
> 
> An exception occurred while executing the Java class. no jacob-1.20-x64 in
> java.library.path:
> 
> C:\Program
> Files\Java\jdk-17\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Cygwin\usr\local\bin;C:\Cygwin\bin;C:\Program
> Files\Common
> Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program
> Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\NVIDIA
> Corporation\NVIDIA
> NvDLISR;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program
> Files (x86)\Common Files\Intuit\QBPOSSDKRuntime;C:\Program
> Files\Google\Google Apps Sync;C:\Program
> Files\Maven\bin;C:\Users\neil\AppData\Local\Microsoft\WindowsApps;. ->
> [Help 1]
> 
> 
> 
> The directory I passed to the command is not listed I the set of
> directories in the output so I can only
> 
> assume the argument did not work.
> 
> 
> 
> I searched but I can’t find any info on this.  Any idea what I am doing
> wrong?
> 
> 
> 
> Thank you,
> 
>   Neil
> 
> 
> 
> --
> 
> Neil Aggarwal, 972-834-1565, http://propfinancing.com
> 
> We offer 30 year loans on single family houses!


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

Re: Unexpected behavior of the javadoc plugin?

[Nils Breunese]

 or  elements are not imported when a project imports a BOM with 
import, only  is imported.

Other elements only get inherited when a project uses another project as a 
parent.

> Op 8 jan 2024, om 20:57 heeft Ceki Gulcu  het volgende 
> geschreven:
> 
> Hi Tamás,
> 
> Thank you for your comments.
> 
> My question is more regarding the need to place a javadoc 
> element in the BOM file, i.e top level pom.xml, instead of parent/pom.xml.
> 
> Once the javadoc related  element is in the BOM file, it works fine.
> 
> However, given the BOM file is intended to be imported, I would prefer
> to keep it minimal and have it free of any  and  elements
> in order to not pollute importing projects.
> 
> Is my concern warranted?
> 
> -- 
> Ceki Gülcü
> 
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
> 
> On 12/28/2023 7:17 PM, Tamás Cservenák wrote:
>> Hej Ceki,
>> 
>> I also experience javadoc misbehaviour when JPMS/jigsaw is involved, and _I
>> think_ it boils down when it tries to be "smart" when it comes to JPMS...
>> See master of maven-resolver, as it was suffering with similar issues, and
>> this change:
>> https://github.com/apache/maven-resolver/commit/baac2975488adf630c02141b882d1459d8c66fae
>> (that was a few releases ago, things may have changed around).
>> 
>> Try out this flag if you are on fairly new version:
>> https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#legacymode
>> 
>> HTH
>> Tamas
>> 
>> On Thu, Dec 28, 2023 at 7:04 PM Ceki Gulcu  wrote:
>> 
>>> 
>>> Hello all,
>>> 
>>> Given the javadoc generation is an important part of software projects,
>>> maybe someone would care to comment whether the behavior described below
>>> is expected or not?
>>> 
>>> In the meantime, happy new year to all,
>>> 
>>> --
>>> Ceki Gülcü
>>> 
>>> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
>>> 
>>> On 12/23/2023 9:34 PM, Ceki Gulcu wrote:
 
 Hello,
 
 I would like to share what looks to me like an unexpected behavior of
 the javadoc plugin, more specifically when run as javadoc:aggregate.
 
 
 The SLF4J project uses the "Refining the BOM Pattern" variant as
 explained in Garret Wilson's "Improving the BOM Pattern" [1]. More
 specifically, the top level pom.xml is the BOM and project modules
 import ../parent/pom.xml.
 
 Source code is available at [2].
 
 Also, version 2.1.0-alpha0-SNAPSHOT is a fully jigsaw modularized
>>> project.
 
 When trying to create aggregated javadocs with the javadoc:aggreate
 command, the javadoc generation would fail with javadoc complaining
 about unnamed modules and other miscellaneous problems. The solution was
 to skip certain modules for which there was no need to generate javadocs
 to begin with.
 
 Surprisingly, adding  in parent/pom.xml of the
 javdoc-plugin configuration would have no effect. However, specifying
 -Dmaven.javadoc.skippedModules would work as expected.
 
 The advice commonly found on various forum about the placement of the
 javadoc plugin configuration pertain to  and/or 
 section. In my case, this advice looks irrelevant (see below).
 
 After a lot of head scratching, placing the javadoc-plugin configuration
 in the BOM, i.e. the top-level pom.xml, made the javadoc-plugin
 configuration have the desired effect. This is quite surprising as the
 configuration of other plugins have an effect when placed in
>>> parent/pom.xml.
 
 To reproduce this behavior, you can check out the code of the SLF4J
 project from [2] and run "mvn javadoc:aggregate". (To observe a failure
 the javadoc-plugin configuration needs to commented out in top-level
 pom.xml and uncommented in parent/pom.xml before running "mvn
 javadoc:aggregate".)
 
 I am wondering whether the behavior of javadoc:aggregate described above
 is expected or actually a problem?
 
 Best regards,
 
 [1]
>>> https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern
 [2] https://github.com/qos-ch/slf4j/tree/branch_2.1.x
 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

[Nils Breunese]

I can’t comment on your question directly, but I just wanted to say that your 
use case sounds like it could benefit from the Maven Build Cache Extension 
(https://maven.apache.org/extensions/maven-build-cache-extension/).

Just my 2 cents.

Nils.

> Op 6 feb 2024 om 11:40 heeft Joseph Leonard  
> het volgende geschreven:
> 
> Hi all,
> 
> It would be great to get any thoughts on whether the following is a defect:
> 
> 
> Issue details:
> tl;dr
> 
> Maven can resolve dependencies either from:
> 
>  *   an external repo
>  *   a class directory of a module being built within the reactor
>  *   a packaged jar of a module being built within the reactor
> 
> If you run a concurrent multi-module build it is possible to get a race 
> condition whereby the build of module Foo may resolve module Bar from either 
> of the three resolution channels. This inconsistency can result in the Maven 
> war plugin sometimes failing to build a functional war file. I would expect a 
> consistent resolution would always take place.
> 
> Full details
> Scenario
> 
> Consider you have a repo with the following structure:
> 
>   App
> 
> / \
> 
>/   \
> 
>   (compile scope)  (test scope)
> 
>  /   \
> 
>\/_   _\/
> 
> ModuleA  TestSupportModule1
> 
>/
> 
>   /
> 
>(compile scope)
> 
> /
> 
>   \/_
> 
>ModuleB
> 
>   /
> 
>  /
> 
>(test scope)
> 
>/
> 
>  \/_
> 
> TestSupportModule2
> 
> If you were to make a src code change to the following test support modules:
> 
>  *   TestSupportModule1
>  *   TestSupportModule2
> 
> Then the minimum number of modules we need to build to verify the change set 
> is OK is:
> 
>  *   TestSupportModule1
>  *   TestSupportModule2
>  *   ModuleB
>  *   App
> 
> i.e. there is no requirement to build ModuleA because we know that none of 
> the src code changes could impact the classpaths used in its maven build.
> 
> We know that despite 'App' depending (transitively) on ModuleB there is no 
> need for the 'App' build to wait for ModuleB to complete its build because 
> the src code change to TestSupportModule2 will not impact any of the 
> classpaths used in the App maven build. Therefore to get the most efficient 
> build possible we ideally would invoke Maven to run with 2 threads and with 
> instruction to build two distinct 'dependency graphs':
> 
>  *   TestSupportModule1 followed by ModuleB
>  *   TestSupportModule1 followed by App
> 
> The following Maven command achieves exactly what we want because the reactor 
> build order is based only on the direct (i.e. non-transitive) dependencies of 
> the modules provided to the reactor in the build command. Therefore the 
> absence of ModuleA results in two distinct 'dependency graphs':
> 
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
> 
> Note: In reality the code base I maintain has a very large monobuild with 
> 100s of modules and this type of build optimisation makes a significant 
> difference to the speed of our monobuild (we use 
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
> automate the logic of determining which modules to include in the reactor 
> based on our change set).
> 
> Issue
> 
> We have encountered an issue in the above scenario because the 'App' build 
> has a race condition with the ModuleB build which will result in one of the 
> following three outcomes:
> 
>  *   If the 'App' build starts before the ModuleB build has compiled its src 
> classes then the 'App' build will resolve ModuleB from the external repo 
> (i.e. equivalent to ModuleB not being in the reactor at all)
>  *   If the 'App' build starts after ModuleB has compiled its src classes but 
> before it has packaged these classes into a jar then the 'App' build will 
> resolve ModuleB's target/classes directory
>  *   If the 'App' build starts after ModuleB has packaged its jar file then 
> the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> 
> In many scenarios this dependency resolution inconsistency doesn't represent 
> a challenge. However, it does cause an issue in our case because the 'App' 
> POM has its Maven packaging stanza configured to war and in the scenario 
> where ModuleB's target/classes directory is resolved by the 'App' then this 
> results in the resultant 'App' war file being packaged with a completely 
> empty ModuleB.jar file.
> 
> Proposed solution
> 
> Ideally we would like the Maven reactor to retain isolation between the two 
> distinct 'dependency graphs' it constructs at instantiation throughout the 
> entire Maven build. This would mean, in the simple example above, that the 
> 'App' would always resolves ModuleB from the external repo (regardless of 
> whether the reactor has built ModuleB or not in a separate 'dependency g

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

[Nils Breunese]

Hi Jospeh,

I didn’t necessarily expect that enabling the extension would solve/avoid the 
issue you described, but I mentioned it, because it would allow you to not have 
to specify an argument like '-pl 
TestSupportModule1,TestSupportModule2,ModuleB,App’ in the first place, because 
the Build Cache Extension should automatically determine which modules need to 
be built and for which ones previously cached artifacts can be used.

Nils.

> Op 6 feb 2024, om 15:11 heeft Joseph Leonard  
> het volgende geschreven:
> 
> Thanks Nils,
> maven-build-cache-extension looks very interesting generally – I will have a 
> play with it.
> With regards to this issue, the maven-build-cache-extension overview 
> references “Subtree support for multimodule projects builds part of the 
> codebase in isolation” which sounded similar to the solution I am proposing 
> for this issue. Unfortunately, after enabling the maven-build-cache-extension 
> I still hit the same issue.
> Joe
> 
> On 2024/02/06 12:54:59 Nils Breunese wrote:
>> I can’t comment on your question directly, but I just wanted to say that 
>> your use case sounds like it could benefit from the Maven Build Cache 
>> Extension (https://maven.apache.org/extensions/maven-build-cache-extension/).
> 
>> 
>> Just my 2 cents.
>> 
>> Nils.
>> 
>>> Op 6 feb 2024 om 11:40 heeft Joseph Leonard  het 
>>> volgende geschreven:
>>> 
>>> Hi all,
>>> 
>>> It would be great to get any thoughts on whether the following is a defect:
>>> 
>>> 
>>> Issue details:
>>> tl;dr
>>> 
>>> Maven can resolve dependencies either from:
>>> 
>>> *   an external repo
>>> *   a class directory of a module being built within the reactor
>>> *   a packaged jar of a module being built within the reactor
>>> 
>>> If you run a concurrent multi-module build it is possible to get a race 
>>> condition whereby the build of module Foo may resolve module Bar from 
>>> either of the three resolution channels. This inconsistency can result in 
>>> the Maven war plugin sometimes failing to build a functional war file. I 
>>> would expect a consistent resolution would always take place.
> 
>>> 
>>> Full details
>>> Scenario
>>> 
>>> Consider you have a repo with the following structure:
>>> 
>>>  App
>>> 
>>>/ \
>>> 
>>>   /   \
>>> 
>>>  (compile scope)  (test scope)
>>> 
>>> /   \
>>> 
>>>   \/_   _\/
>>> 
>>>ModuleA  TestSupportModule1
>>> 
>>>   /
>>> 
>>>  /
>>> 
>>>   (compile scope)
>>> 
>>>/
>>> 
>>>  \/_
>>> 
>>>   ModuleB
>>> 
>>>  /
>>> 
>>> /
>>> 
>>>   (test scope)
>>> 
>>>   /
>>> 
>>> \/_
>>> 
>>> TestSupportModule2
>>> 
>>> If you were to make a src code change to the following test support modules:
>>> 
>>> *   TestSupportModule1
>>> *   TestSupportModule2
>>> 
>>> Then the minimum number of modules we need to build to verify the change 
>>> set is OK is:
>>> 
>>> *   TestSupportModule1
>>> *   TestSupportModule2
>>> *   ModuleB
>>> *   App
>>> 
>>> i.e. there is no requirement to build ModuleA because we know that none of 
>>> the src code changes could impact the classpaths used in its maven build.
> 
>>> 
>>> We know that despite 'App' depending (transitively) on ModuleB there is no 
>>> need for the 'App' build to wait for ModuleB to complete its build because 
>>> the src code change to TestSupportModule2 will not impact any of the 
>>> classpaths used in the App maven build. Therefore to get the most efficient 
>>> build possible we ideally would invoke Maven to run with 2 threads and with 
>>> instruction to build two distinct 'dependency graphs':
> 
>>> 
>>> *   TestSupportModule1 followed by ModuleB
>>> *   TestSupportModule1 followed by App
>>> 
>>> The following Maven command achieves exactly what we want because the 
>>> reactor build order is based only on the direct (i.e. non-transitive) 
>>> dependencies 

Re: problem resolving LATEST dependency in the local repo

[Nils Breunese]

I recommend using a bot like Dependabot or Renovate to keep dependencies 
up-to-date.

Nils.

> Op 29 feb 2024, om 16:05 heeft Tamás Cservenák  het 
> volgende geschreven:
> 
> Correct!
> It says "Maven 3.x no longer supports usage of these metaversions in the
> POM"
> 
> T
> 
> On Thu, Feb 29, 2024 at 4:04 PM Alan Snyder 
> wrote:
> 
>> The Maven 3 compatibility notes page can be read as saying that RELEASE
>> and LATEST are deprecated only for finding plugins, although it can also be
>> read as a general statement.
>> 
>> Which is the correct interpretation?
>> 
>> I quote:
>> 
>> Given the threat of non-reproducible builds imposed by automatic plugin
>> version resolution, this feature is scheduled for removal as far as plugin
>> declarations in the POM are concerned.
>> Internally, Maven 2.x used the special version markers RELEASE and LATEST
>> to support automatic plugin version resolution. These metaversions were
>> also recognized in the  element for a  declaration. For
>> the sake of reproducible builds, Maven 3.x no longer supports usage of
>> these metaversions in the POM. As a result, users will need to replace
>> occurrences of these metaversions with a concrete version.
>> 
>> Source:
>> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution
>> 
>> I understand the drawbacks of using LATEST and RELEASE, but there are
>> situations where they are useful.
>> 
>> I should have stated explicitly that LATEST is resolved correctly for
>> artifacts in Maven Central.
>> 
>> 
>> 
>>> On Feb 29, 2024, at 12:40 AM, Tamás Cservenák 
>> wrote:
>>> 
>>> Howdy,
>>> 
>>> Yes, the "LATEST" Maven2 version keyword has been phased out in Maven3.
>>> They make builds non reproducible (just like snapshots): as it is a
>> "moving
>>> target".
>>> 
>>> T
>>> 
>>> 
>>> On Thu, Feb 29, 2024, 03:01 Alan Snyder 
>>> wrote:
>>> 
 I have been using the Maven Artifact Resolver Ant Tasks with success,
 except in one situation:
 
 When the artifact exists only in my local repo (with version
>> 1-SNAPSHOT),
 a dependency with version LATEST fails to resolve.
 
 An example of the error message:
 
 Could not collect dependencies: Failed to collect dependencies at
 org.violetlib:nls:jar:LATEST
 
 If I change the dependency to use 1-SNAPSHOT as the version, the
>> resolver
 succeeds.
 
 Is it intentional that a local repo does not support LATEST?
 
 In case it matters, the artifact was installed in the local repo using
>> mvn
 install:install-file.
 
 
 
>> 
>> 


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

Re: POM license guidance (and need for documentation/FAQ)

[Nils Breunese]

I personally omit the  element when there are no applicable licenses. 
But it sounds like you'd want to be able to distinguish between ’there are no 
applicable licenses’ and ’there may or may not be applicable licenses’?

Nils.

> Op 27 mrt 2024, om 16:38 heeft Timothy Stone  het 
> volgende geschreven:
> 
> I'm trying to improve the use of POM meta-data such as  in our 
> internal projects.
> 
> However, proprietary code, i.e., "unlicensed" code, is not explicitly 
> documented in the POM Reference[1].
> 
> A search of the mailing list did not turn up any discussions in the past 
> (though how far back that search looked may be in question).
> 
> The SPDX does not recognize "UNLICENSED" (though NPM does) and NOT to be 
> confused with "The Unlicense" (SPDX "Unlicense").
> 
> How does the community manage this? Is this a documentation PR opportunity 
> based on feedback here? A best practice is sought.
> 
> The explicit recommendation for documenting the recommended pattern in the 
> POM would be valuable to many organizations.
> 
> Thanks!
> Tim
> 
> [1]. https://maven.apache.org/pom.html#licenses
> 
> -- 
> Timothy Stone
> =
> Some call me ... Tim.
> Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D
> Find me on GitLab | GitHub | Linked In | MeWe | GnuPG


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

Re: POM license guidance (and need for documentation/FAQ)

[Nils Breunese]

That sounds like a good idea when the code is actually licensed under the 
“Companyname Commercial License”, but if code is proprietary and there is no 
desire to license it to anyone, it should not be necessary to create such a 
license. Code is proprietary by default, you only need to license it when you 
want to define under which circumstances and in what ways others are also 
allowed to use the code. No license means others are not allowed to use it.

Nils.

> Op 27 mrt 2024, om 20:11 heeft Bernd Eckenfels  het 
> volgende geschreven:
> 
> I use name=„Companyname Commercial License“, 
> url=„https://www.companyname.com/terms“, distribution=„manual“ but also think 
> it would be good to have standard distribution and classifier for properitary 
> code.
> 
> Nils Breunese wrote on 27. Mar 2024 20:02 (GMT +01:00):
>> I personally omit the  element when there are no applicable
>> licenses. But it sounds like you'd want to be able to distinguish between
>> ’there are no applicable licenses’ and ’there may or may not be
>> applicable licenses’?
> 
> Gruss
> Bernd
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: POM license guidance (and need for documentation/FAQ)

[Nils Breunese]

Timothy Stone  wrote:

> Organizationally, we lack a policy and much of our code lacks even a 
> "copyright."

Where I live (The Netherlands) there is no need to explicitly add a copyright 
notice to the work you create, you automatically have the copyright on anything 
you create (not just software). But laws are not the same all over the world, 
which I guess is why many organizations add an explicit copyright notice in 
each individual source file.

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

Re: POM license guidance (and need for documentation/FAQ)

[Nils Breunese]

Alexander Kriegisch  wrote:

> I think what Nils says applies internationally, not just in the NL. A
> copyright claim for any project which sports at least one easily
> discoverable licence file in its SCM and in each major artifact should
> be easy to defend against any licence violations. Legally, redundant
> copies are totally unnecessary.

My point was that even when there is no copyright notice anywhere, legally 
means that nobody except the author is allowed to use the code. At least in The 
Netherlands. Other countries may require an explicit copyright notice. Of 
course having an explicit copyright notice may help when there is a copyright 
dispute.

When there is no license, there can also be no license violation, but default 
copyright rules apply when there is no license. You only need to license 
something when you want to deviate from standard copyright rules.

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

Re: [ANN] Apache Maven Wrapper 3.3.0 Released

[Nils Breunese]

I use Renovate [0] to automatically keep dependencies up-to-date. I noticed 
that the upgrade to Maven Wrapper 3.3.0 removed the `wrapperUrl` line from 
`.mvn/wrapper/maven-wrapper.properties`. I guess that is related to 
https://issues.apache.org/jira/browse/MWRAPPER-120.

A couple of my colleagues implemented the support for keeping Maven Wrapper 
up-to-date in Renovate, and I believe Renovate currently determines the version 
of Maven Wrapper based on the `wrapperUrl` property, so I think that logic may 
need to be updated after this change. Is parsing the `mvnw` / `./mvnw.bat` 
scripts themselves the only way to determine the Maven Wrapper version after 
this change?

Nils.

[0] https://github.com/renovatebot/renovate

> Op 20 apr 2024, om 11:11 heeft Tamás Cservenák  het 
> volgende geschreven:
> 
> The Apache Maven team is pleased to announce the release of the Apache
> Maven Wrapper, version 3.3.0
> 
> The Maven Wrapper is an easy way to ensure a user of your Maven build has
> everything necessary to run your Maven build.
> 
> See https://maven.apache.org/wrapper/ for instructions on how to use Maven
> Wrapper.
> 
> You can download the appropriate sources etc. from the download page:
> 
> https://maven.apache.org/wrapper/download.html
> 
> Release Notes - Maven Wrapper - Version 3.3.0
> 
> ** Bug
>* [MWRAPPER-86] - Trim trailing slash in Repo URL
>* [MWRAPPER-103] - Failed to validate Maven Wrapper SHA-256 on Windows
>* [MWRAPPER-108] - mvnw script fails silently when download fails
>* [MWRAPPER-112] - Detection of JAVA_HOME fails due to bad quoting
>* [MWRAPPER-113] - Error and warning output goes to standard output and
> intermingles with Maven output
>* [MWRAPPER-120] - Maven wrapper plugin should not create wrapperUrl
> property for script-only mode
>* [MWRAPPER-123] - only-mvnw fails on ksh printf implementations
>* [MWRAPPER-131] - Downloader downloads directly into target file
> ** Improvement
>* [MWRAPPER-70] - Don't require a pom.xml
>* [MWRAPPER-104] - Add prettier config for shell scripts
>* [MWRAPPER-124] - MavenWrapperDownloader uses new URL(String), which
> is deprecated in Java 21
>* [MWRAPPER-125] - Make "only-script" the default wrapper
> ** Task
>* [MWRAPPER-128] - Remove legacy
>* [MWRAPPER-129] - Set plugin prerequisite to Maven 3.6.3
> ** Dependency upgrade
>* [MWRAPPER-100] - Declare needed dependencies
>* [MWRAPPER-115] - Bump org.codehaus.plexus:plexus-archiver from 4.6.2
> to 4.9.1
>* [MWRAPPER-118] - Bump org.codehaus.mojo:mrm-maven-plugin from 1.5.0
> to 1.6.0
>* [MWRAPPER-119] - Upgrade Parent to 41
>* [MWRAPPER-126] - Upgrade org.codehaus.plexus:plexus-archiver to 4.9.2
>* [MWRAPPER-127] - Bump commons-io:commons-io from 2.16.0 to 2.16.1
>* [MWRAPPER-130] - Use Maven parent 42
> 
> Enjoy,
> -The Apache Maven team

Re: [ANN] Apache Maven Wrapper 3.3.0 Released

[Nils Breunese]

I’ve created a ticket for this: 
https://issues.apache.org/jira/browse/MWRAPPER-134

Nils.

> Op 22 apr 2024, om 12:30 heeft Tamás Cservenák  het 
> volgende geschreven:
> 
> Agreed!
> 
> On Mon, Apr 22, 2024 at 12:27 PM Slawomir Jaranowski 
> wrote:
> 
>> I would like to not add something which must be parsed in a magical way ...
>> we can add a property that can be simply used.
>> 
>> pon., 22 kwi 2024 o 12:06 Tamás Cservenák 
>> napisał(a):
>> 
>>> Good call...
>>> 
>>> seems so... maybe we need to add some (clearly visible/parsable) value
>> into
>>> script, probably interpolated during build?
>>> 
>>> T
>>> 
>>> On Mon, Apr 22, 2024 at 11:46 AM Nils Breunese  wrote:
>>> 
>>>> I use Renovate [0] to automatically keep dependencies up-to-date. I
>>>> noticed that the upgrade to Maven Wrapper 3.3.0 removed the
>> `wrapperUrl`
>>>> line from `.mvn/wrapper/maven-wrapper.properties`. I guess that is
>>> related
>>>> to https://issues.apache.org/jira/browse/MWRAPPER-120.
>>>> 
>>>> A couple of my colleagues implemented the support for keeping Maven
>>>> Wrapper up-to-date in Renovate, and I believe Renovate currently
>>> determines
>>>> the version of Maven Wrapper based on the `wrapperUrl` property, so I
>>> think
>>>> that logic may need to be updated after this change. Is parsing the
>>> `mvnw`
>>>> / `./mvnw.bat` scripts themselves the only way to determine the Maven
>>>> Wrapper version after this change?
>>>> 
>>>> Nils.
>>>> 
>>>> [0] https://github.com/renovatebot/renovate
>>>> 
>>>>> Op 20 apr 2024, om 11:11 heeft Tamás Cservenák 
>>> het
>>>> volgende geschreven:
>>>>> 
>>>>> The Apache Maven team is pleased to announce the release of the
>> Apache
>>>>> Maven Wrapper, version 3.3.0
>>>>> 
>>>>> The Maven Wrapper is an easy way to ensure a user of your Maven build
>>> has
>>>>> everything necessary to run your Maven build.
>>>>> 
>>>>> See https://maven.apache.org/wrapper/ for instructions on how to use
>>>> Maven
>>>>> Wrapper.
>>>>> 
>>>>> You can download the appropriate sources etc. from the download page:
>>>>> 
>>>>> https://maven.apache.org/wrapper/download.html
>>>>> 
>>>>> Release Notes - Maven Wrapper - Version 3.3.0
>>>>> 
>>>>> ** Bug
>>>>>   * [MWRAPPER-86] - Trim trailing slash in Repo URL
>>>>>   * [MWRAPPER-103] - Failed to validate Maven Wrapper SHA-256 on
>>> Windows
>>>>>   * [MWRAPPER-108] - mvnw script fails silently when download fails
>>>>>   * [MWRAPPER-112] - Detection of JAVA_HOME fails due to bad quoting
>>>>>   * [MWRAPPER-113] - Error and warning output goes to standard
>> output
>>>> and
>>>>> intermingles with Maven output
>>>>>   * [MWRAPPER-120] - Maven wrapper plugin should not create
>> wrapperUrl
>>>>> property for script-only mode
>>>>>   * [MWRAPPER-123] - only-mvnw fails on ksh printf implementations
>>>>>   * [MWRAPPER-131] - Downloader downloads directly into target file
>>>>> ** Improvement
>>>>>   * [MWRAPPER-70] - Don't require a pom.xml
>>>>>   * [MWRAPPER-104] - Add prettier config for shell scripts
>>>>>   * [MWRAPPER-124] - MavenWrapperDownloader uses new URL(String),
>>> which
>>>>> is deprecated in Java 21
>>>>>   * [MWRAPPER-125] - Make "only-script" the default wrapper
>>>>> ** Task
>>>>>   * [MWRAPPER-128] - Remove legacy
>>>>>   * [MWRAPPER-129] - Set plugin prerequisite to Maven 3.6.3
>>>>> ** Dependency upgrade
>>>>>   * [MWRAPPER-100] - Declare needed dependencies
>>>>>   * [MWRAPPER-115] - Bump org.codehaus.plexus:plexus-archiver from
>>> 4.6.2
>>>>> to 4.9.1
>>>>>   * [MWRAPPER-118] - Bump org.codehaus.mojo:mrm-maven-plugin from
>>> 1.5.0
>>>>> to 1.6.0
>>>>>   * [MWRAPPER-119] - Upgrade Parent to 41
>>>>>   * [MWRAPPER-126] - Upgrade org.codehaus.plexus:plexus-archiver to
>>>> 4.9.2
>>>>>   * [MWRAPPER-127] - Bump commons-io:commons-io from 2.16.0 to
>> 2.16.1
>>>>>   * [MWRAPPER-130] - Use Maven parent 42
>>>>> 
>>>>> Enjoy,
>>>>> -The Apache Maven team
>>>> 
>>>> 
>>> 
>> 
>> 
>> --
>> Sławomir Jaranowski
>> 

Re: [ANN] Apache Maven Wrapper 3.3.1 Released

[Nils Breunese]

Tamás Cservenák  wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven Wrapper, version 3.3.1
> 
> The Maven Wrapper is an easy way to ensure a user of your Maven build has
> everything necessary to run your Maven build.
> 
> See https://maven.apache.org/wrapper/ for instructions on how to use Maven
> Wrapper.
> 
> You can download the appropriate sources etc. from the download page:
> 
> https://maven.apache.org/wrapper/download.html
> 
> Release Notes - Maven Wrapper - Version 3.3.1
> 
> ** Improvement
>* [MWRAPPER-132] - Inlined mvnw Downloader.java uses `new URL(String)`,
> which is deprecated in Java 21
>* [MWRAPPER-134] - Provide a reliable way to determine the Maven
> Wrapper version

Thanks for this new feature, the new `wrapperVersion` property will make it 
easier for update bots like Renovate to automatically suggest updating to a 
newer version of Maven Wrapper. Work for Renovate is happening already via 
https://github.com/renovatebot/renovate/discussions/28648.

I have one more question though: because the default type changes from `bin` to 
`only-script` with Maven Wrapper 3.3.0, all of our projects also got changed 
from `bin` to `only-script`, because Renovate’s upgrade command doesn’t 
explicitly set `-Dtype=${type}`.

Is there a way to upgrade an existing Maven Wrapper installation to a newer 
version of the same type without having to specify `-Dtype=${type}` to match 
the current installation type? If not, would you consider also introducing a 
`wrapperType` property in `.mvn/wrapper/maven-wrapper.properties`, so external 
tools can determine the installation type to use for the update?

Thanks, Nils.

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

Re: Less info please.

[Nils Breunese]

See https://maven.apache.org/maven-logging.html for information on how to 
configure Maven logging. You can either configure this globally or for a 
specific project or Maven invocation. When using the default SLF4J Simple 
logging implementation, you can override the 
`org.slf4j.simpleLogger.defaultLogLevel` property to change which messages get 
logged based on their log level. Set it to `error` to only see messages with 
level `error` or higher.

Nils.

> Op 3 mei 2024 om 12:32 heeft Arbol One  het volgende 
> geschreven:
> 
> Debian 12
> NetBeans 21
> Apache Maven 3.8.7
> 
> Hello.
> 
> The Ant tool produces very little information regarding its work. On the 
> other hand, Maven displays lots and lots of output telling me what's 
> happening under the hood.
> I am not interested in so much data about what Maven does in the background, 
> all I need to know, for now, is that there are not errors and what the 
> compilation output is.
> 
> What can I do to make Maven display less data about what it does under the 
> hood?
> 
> Thanks in advance!
> 
> --
> */ArbolOne.ca/* Using Fire Fox and Thunderbird. ArbolOne is composed of 
> students and volunteers dedicated to providing free services to charitable 
> organizations. ArbolOne on Java Development is in progress [ í ]

Re: Maven && NetBeans && outputWindow && colours

[Nils Breunese]

Maven colors logging output by default when possible (`--color=auto`, see 
https://maven.apache.org/ref/3.8.7/maven-embedder/cli.html), so Maven code 
(including plugins) should log errors via the logging API used by Maven (SLF4J, 
see https://maven.apache.org/maven-logging.html) instead of `System.err`.

Or are you looking to colorize errors from your application when it is run by 
Maven, instead of errors logged by Maven or one of its plugins?

Nils.

> Op 3 mei 2024 om 12:25 heeft Arbol One  het volgende 
> geschreven:
> 
> Debian 12
> NetBeans 21
> Apache Maven 3.8.7
> 
> Hello.
> 
> When using the Ant tool System.err.println() displays data in red, however, 
> when using Maven, the same expression does not produce a coloured output.
> I'd very much like the ..err.. output be in red colour. So, what can I do to 
> make Maven display ..err.. outputs in red?
> 
> 
> --
> */ArbolOne.ca/* Using Fire Fox and Thunderbird. ArbolOne is composed of 
> students and volunteers dedicated to providing free services to charitable 
> organizations. ArbolOne on Java Development is in progress [ í ]

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 best practice for multiple mains

[Nils Breunese]

You can have separate projects, or a single multi-module project. I’d say one 
is not necessarily better or worse than the other. Like so often “it depends”, 
both on your preferences and the nature of the project, and the organization of 
the people/teams around this code (if applicable).

What will the lifecycle of these projects look like? If you expect the server 
and client projects to typically evolve in tandem, I would personally probably 
use a single multi-module project, so server and client can be built from a 
single Maven project.

If server and client are likely to evolve separately, or will be managed by 
separate teams, with separate release schedules, etc., then separate projects 
(and source code repositories, access rights, etc.) may be preferable.

Will the client and server projects share anything (API definition, models, 
etc.)? If so, you’ll want to create a third module for that and use it as a 
dependency for both the server and client projects.

Nils.

Keith Brown  wrote:

> I am writing a client/server utility. They are CLI tools. I keep them
> in separate maven projects.
> 
> mkdir -p proj && cd proj
> 
> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=client
> -DarchetypeArtifactId=maven-archetype-quickstart
> -DarchetypeVersion=1.4 -DinteractiveMode=false
> 
> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=server
> -DarchetypeArtifactId=maven-archetype-quickstart
> -DarchetypeVersion=1.4 -DinteractiveMode=false
> 
> 
> Is this a good practice? Or can I have both server and client in a
> single maven project?

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