from:"Garret Wilson"

Re: finding source of outdated dependencies

2023-11-09 Thread Garret Wilson

Ah! So, reading between the lines, you're recommending that I issue this 
command:


    mvn help:effective-pom -Dverbose=true

I didn't know there was a `verbose` option for the effective POM that 
had anything to do with dependency management. Thanks. That gives me 
effective dependency management, along with the POM it comes from—even 
with line numbers. Nice!


And (drumroll …) it looks like 
`biz.aQute.bnd:biz.aQute.bnd.annotation:6.4.1` is coming from 
`org.apache.logging:logging-parent:10.1.1`.


And `org.mockito:mockito-inline:4.8.1` was getting in because one of my 
own dependencies 😊 hasn't been updated to use my newer root POM, which 
manages the versions of testing libraries. hehe It's good to find 
out—and now to know /how/ to find out.


Thanks, Tamás.

Garret

On 11/9/2023 5:25 PM, Tamás Cservenák wrote:

Well, depMgt is "flattened" (so if depMgt import of POM imports another POM
and ...), and if you use verbose with effective, you will see the source of
flattened things, at least

T

On Thu, Nov 9, 2023 at 9:18 PM Garret Wilson
wrote:


On 11/9/2023 5:10 PM, Tamás Cservenák wrote:

Howdy,

Did you try to take a peek at effective POM?

Hi. The effective POM doesn't show me anything helpful—and I don't know
that I expected it to. The effective POM simple resolves the inheritance
tree, right? I don't know if that would have any relationship to
transitive dependency management.


But also,https://issues.apache.org/jira/browse/MPH-183

So that seems to be a suggestion someone made to make the effective POM
show something about dependency management, but was never
finished/integrated?

Garret


On Thu, Nov 9, 2023 at 9:04 PM Garret Wilson
wrote:


In my Maven project (an aggregate project with child projects) I issue
the following command for the Versions Maven Plugin:

   mvn versions:display-dependency-updates

There are a couple of outdated dependencies I'm not sure where are
coming from:

[INFO] The following dependencies in Dependency Management have newer
versions:
[INFO]   biz.aQute.bnd:biz.aQute.bnd.annotation  6.4.1
-> 7.0.0
[INFO]   org.mockito:mockito-inline  4.8.1
-> 5.2.0

Unfortunately, try as I might, I can't find which library references
these. I've tried the following with the Maven Dependency Plugin, both
in the root project and in child projects:

   mvn dependency:tree

None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or
`org.mockito:mockito-inline`.

The two suspects are:

* `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or
`org.apache.logging.log4j:log4j-bom:2.21.1` (for
`biz.aQute.bnd:biz.aQute.bnd.annotation`)
* `com.fasterxml.jackson:jackson-bom:2.15.3` (for
`org.mockito:mockito-inline`)

But those are just suspicions based upon the additional dependency
management I have in the subprojects where those outdated dependencies
show up.

Is there any command I can use to find out which dependency is bringing
in the outdated dependencies listed by the Versions Maven Plugin?

Thanks,

Garret


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

Re: finding source of outdated dependencies

2023-11-09 Thread Garret Wilson


On 11/9/2023 5:10 PM, Tamás Cservenák wrote:

Howdy,

Did you try to take a peek at effective POM?


Hi. The effective POM doesn't show me anything helpful—and I don't know 
that I expected it to. The effective POM simple resolves the inheritance 
tree, right? I don't know if that would have any relationship to 
transitive dependency management.



But also,https://issues.apache.org/jira/browse/MPH-183


So that seems to be a suggestion someone made to make the effective POM 
show something about dependency management, but was never 
finished/integrated?


Garret


On Thu, Nov 9, 2023 at 9:04 PM Garret Wilson
wrote:


In my Maven project (an aggregate project with child projects) I issue
the following command for the Versions Maven Plugin:

  mvn versions:display-dependency-updates

There are a couple of outdated dependencies I'm not sure where are
coming from:

[INFO] The following dependencies in Dependency Management have newer
versions:
[INFO]   biz.aQute.bnd:biz.aQute.bnd.annotation  6.4.1
-> 7.0.0
[INFO]   org.mockito:mockito-inline  4.8.1
-> 5.2.0

Unfortunately, try as I might, I can't find which library references
these. I've tried the following with the Maven Dependency Plugin, both
in the root project and in child projects:

  mvn dependency:tree

None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or
`org.mockito:mockito-inline`.

The two suspects are:

* `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or
`org.apache.logging.log4j:log4j-bom:2.21.1` (for
`biz.aQute.bnd:biz.aQute.bnd.annotation`)
* `com.fasterxml.jackson:jackson-bom:2.15.3` (for
`org.mockito:mockito-inline`)

But those are just suspicions based upon the additional dependency
management I have in the subprojects where those outdated dependencies
show up.

Is there any command I can use to find out which dependency is bringing
in the outdated dependencies listed by the Versions Maven Plugin?

Thanks,

Garret


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

finding source of outdated dependencies

2023-11-09 Thread Garret Wilson

In my Maven project (an aggregate project with child projects) I issue 
the following command for the Versions Maven Plugin:


    mvn versions:display-dependency-updates

There are a couple of outdated dependencies I'm not sure where are 
coming from:


[INFO] The following dependencies in Dependency Management have newer 
versions:
[INFO]   biz.aQute.bnd:biz.aQute.bnd.annotation  6.4.1 
-> 7.0.0
[INFO]   org.mockito:mockito-inline  4.8.1 
-> 5.2.0


Unfortunately, try as I might, I can't find which library references 
these. I've tried the following with the Maven Dependency Plugin, both 
in the root project and in child projects:


    mvn dependency:tree

None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or 
`org.mockito:mockito-inline`.


The two suspects are:

* `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or 
`org.apache.logging.log4j:log4j-bom:2.21.1` (for 
`biz.aQute.bnd:biz.aQute.bnd.annotation`)
* `com.fasterxml.jackson:jackson-bom:2.15.3` (for 
`org.mockito:mockito-inline`)


But those are just suspicions based upon the additional dependency 
management I have in the subprojects where those outdated dependencies 
show up.


Is there any command I can use to find out which dependency is bringing 
in the outdated dependencies listed by the Versions Maven Plugin?


Thanks,

Garret


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

Re: [ANN] Maven Surefire 3.2.1 released

2023-10-25 Thread Garret Wilson

Could you clarify whether this means that the plugin will not work 
correctly, and whether we should wait for a patch version that uses the 
correct dependencies instead of upgrading our POMs to use this announced 
version 3.2.1?


Thanks,

Garret

On 10/24/2023 7:42 AM, Thomas Broyer wrote:

This is using plexus-xml 4.0.0 (from Parent 40). Shouldn't that be
downgraded to 3.0.0?
(
https://github.com/apache/maven-parent/commit/096de2d1f79a1b692a112db16675ecc2ac013597
says 4.0.0 is not compatible with Maven 3; maybe a Parent 41 should have
been released after that commit?)

Fwiw, I have a plugin that depends on surefire-common (maybe it shouldn't
but that's another story) and this brings maven-xml-impl et al. that are
flagged as not being in the correct scope (brought in as "compile", should
be "provided"). My tests pass with that version, but I've explicitly
downgraded to 3.0.0 (upgraded plexus-utils to 4.0.0 and added dependency on
plexus-xml 3.0.0) and tests still pass, so I think I'm going to go with
that.

On Mon, Oct 23, 2023 at 10:00 PM Michael Osipov  wrote:


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

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


Release Notes - Maven Surefire - Version 3.2.1

** Bug
  * [SUREFIRE-2190] - optional dependencies and JPMS modules confuse
surefire
  * [SUREFIRE-2196] -
maven-surefire-report-plugin:failsafe-report-only failed: Unmatched
braces in the pattern
  * [SUREFIRE-2202] - NullPointerException if super class meets
specific condition

** New Feature
  * [SUREFIRE-1124] - Let ${surefire.forkNumber} deliver unique
environmentVariables when used in parallel mvn builds

** Improvement
  * [SUREFIRE-2177] - Use junit-bom instead of single JUnit 5 versions
  * [SUREFIRE-2178] - classpathDependencyExcludes should support
classifiers
  * [SUREFIRE-2179] - additionalClasspathElements should support
Maven coordinates
  * [SUREFIRE-2182] - Log starter implementation on DEBUG level

** Dependency upgrade
  * [SUREFIRE-2188] - Upgrade to Parent 40


Enjoy,

-The Apache Maven team

-
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: Authoring Maven Mojos for Maven 3.9.x - Maximum bytecode version=Java14

2023-10-16 Thread Garret Wilson


On 10/16/2023 4:59 PM, Tamás Cservenák wrote:

You'd use Plexus?  In 2023?


I don't know what I'd use. I'm asking. I haven't written a Maven plugin 
yet. I'm just reading the latest documentation, and the [Plugin 
Developers Centre](https://maven.apache.org/plugin-developers/) seems to 
say at https://maven.apache.org/maven-jsr330.html that I either have to 
use Plexus or JSR-330, and you just told me I can't use JSR-330, so that 
leaves Plexus.


If I'm not understanding the documentation correctly, please point out 
what I'm missing.



…
In other words: whatever is "managed by sisu, should be max Java 14"
bytecode in current release Maven versions. Naturally, this does NOT apply
to ANY code, just those being JSR330 (and Mojo) annotated.


Maybe you are saying I can write a Maven plugin without using Plexus or 
JSR-330? So dependency injection in Maven Plugins is optional? The page 
at https://maven.apache.org/maven-jsr330.html makes it seem like 
dependency injection in a Maven Plugin is a common thing.


(Maybe your announcement makes perfect sense to those who have written 
Maven plugins before. In the meantime I'm reading the online 
documentation and trying to understand how this will affect me once I 
write a plugin.)


Garret


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

Re: Authoring Maven Mojos for Maven 3.9.x - Maximum bytecode version=Java14

2023-10-16 Thread Garret Wilson


On 10/16/2023 4:36 PM, Tamás Cservenák wrote:

…

no, this applies to "sisu managed components" ONLY. So not ALL the code
needs to be downgraded, only those annotated with JSR330 annotations.


After reading and trying to understand 
https://maven.apache.org/maven-jsr330.html , does this mean I'll have to 
use the old-style [Plexus 
annotations](https://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/), 
and then just convert to JSR-330 once Maven updates Sisu?


In other words, if I use Plexus annotations I'll be fine with Java 17, 
and have no limitations or problems from not using JSR-330 annotations?


Garret


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

Re: Authoring Maven Mojos for Maven 3.9.x - Maximum bytecode version=Java14

2023-10-16 Thread Garret Wilson

Tamás, thank you very much for the clarification. The previous 
announcement sounded like it applied to every Maven plugin.


Garret

On 10/16/2023 4:36 PM, Tamás Cservenák wrote:

Hej Garret,

no, this applies to "sisu managed components" ONLY. So not ALL the code
needs to be downgraded, only those annotated with JSR330 annotations.
And yes, Maven 3.9.6 could upgrade Sisu to the latest version, basically
lifting this limitation.

HTH
T

On Mon, Oct 16, 2023 at 9:19 PM Garret Wilson 
wrote:


Wait, really? I have an annotation processor being developed now with
Java 17, and parts of it soon will need to move to a Maven plugin. This
means that I'll have to downgrade all the code to Java 14?? In 2023?

Are there any workarounds? The issue #94 you mentioned has already been
closed as addressed. Are you saying that Sisu 0.9.0.M2 fixes the
problem? Can't Maven 3.x simply upgrade to that and release v3.9.6?

Garret

On 10/16/2023 3:45 PM, Tamás Cservenák wrote:

Howdy,

This mail is just a general response (initiated by those asking me in
private): it seems that the Maven team "forgot" to emphasize an important
question on the Maven site, while it is becoming more and more pressing,
especially as Java 17 is out long time ago, and Java 21 is here as well.

In short: if you develop Java Mojo (a Maven plugin), that you plan to use
with current "stable" Maven versions (3.9.x and maybe 3.8,x), your
maven-plugin packaged artifact MUST NOT use Java bytecode that is newer
than Java 14!

What happens is that Eclipse Sisu is unable to inspect the component
class/bytecode 14+ in question (despite is listed on index, in
META-INF/sisu/javax.inject.Named file), and it will silently ignore the
component, "pretend" like it's absent (and error reported will be like
Guice does not find the component to be injected). This can be seen, if

you

make Sisu DEBUG (-Dsisu.debug on maven cli).

Cause of limitation is the version of Eclipse Sisu used in Maven (the
JSR330 container implementation Maven uses internally), see
https://github.com/eclipse/sisu.inject/issues/94. Eclipse Sisu versions
0.3.5 (used in Maven 3.8.x and 3.9.x) uses ASM that is able to scan
bytecode only up to Java 14. Latest release 0.9.0.M2 (used in Maven4) is
covering this up to Java21, while this issue above should fully cover,

and

will probably be updated in Maven4 once released.

So, for plugin devs targeting Maven3, best is to not exceed Java 14

(safest

Java11) bytecode version for components (Mojos and JSR330 components).

HTH
Tamas


-
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: Authoring Maven Mojos for Maven 3.9.x - Maximum bytecode version=Java14

2023-10-16 Thread Garret Wilson

Wait, really? I have an annotation processor being developed now with 
Java 17, and parts of it soon will need to move to a Maven plugin. This 
means that I'll have to downgrade all the code to Java 14?? In 2023?


Are there any workarounds? The issue #94 you mentioned has already been 
closed as addressed. Are you saying that Sisu 0.9.0.M2 fixes the 
problem? Can't Maven 3.x simply upgrade to that and release v3.9.6?


Garret

On 10/16/2023 3:45 PM, Tamás Cservenák wrote:

Howdy,

This mail is just a general response (initiated by those asking me in
private): it seems that the Maven team "forgot" to emphasize an important
question on the Maven site, while it is becoming more and more pressing,
especially as Java 17 is out long time ago, and Java 21 is here as well.

In short: if you develop Java Mojo (a Maven plugin), that you plan to use
with current "stable" Maven versions (3.9.x and maybe 3.8,x), your
maven-plugin packaged artifact MUST NOT use Java bytecode that is newer
than Java 14!

What happens is that Eclipse Sisu is unable to inspect the component
class/bytecode 14+ in question (despite is listed on index, in
META-INF/sisu/javax.inject.Named file), and it will silently ignore the
component, "pretend" like it's absent (and error reported will be like
Guice does not find the component to be injected). This can be seen, if you
make Sisu DEBUG (-Dsisu.debug on maven cli).

Cause of limitation is the version of Eclipse Sisu used in Maven (the
JSR330 container implementation Maven uses internally), see
https://github.com/eclipse/sisu.inject/issues/94. Eclipse Sisu versions
0.3.5 (used in Maven 3.8.x and 3.9.x) uses ASM that is able to scan
bytecode only up to Java 14. Latest release 0.9.0.M2 (used in Maven4) is
covering this up to Java21, while this issue above should fully cover, and
will probably be updated in Maven4 once released.

So, for plugin devs targeting Maven3, best is to not exceed Java 14 (safest
Java11) bytecode version for components (Mojos and JSR330 components).

HTH
Tamas



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

Re: escaping single quote for Exec Maven Plugin `exc.args`

2023-10-15 Thread Garret Wilson

On 10/15/2023 9:24 AM, Garret Wilson wrote:

On 10/15/2023 1:31 AM, Alexander Kriegisch wrote:

…
Let us settle on only using double quotes to enclose arguments
containing spaces. Then, we do not need to escape single quotes and
can use them literally. But we do need to escape nested double quotes.

…
Just for a moment, forget about Bash/PowerShell/CMD escaping rules.
What are escaping the rules of the Maven Exec Plugin? What does it
consider a delimiter for indicating multiple arguments?

I guess at this point it's easier just to dig into the source code. The
relevant plugin source code seems to be here (after a cursory glance):

https://github.com/mojohaus/exec-maven-plugin/blob/ddefecff84ebbf6427a6bb9eb6c2fdb332bfac7c/src/main/java/org/codehaus/mojo/exec/ExecMojo.java#L600

It appears to be using `CommandLineUtils.translateCommandline( argsProp
)` to parse the string input into an array. A little more searching
seems to indicate that that utility is here:

https://github.com/codehaus-plexus/plexus-utils/blob/d4f0d2de40c5d6cb5d80c8a199fa4f32a4e59879/src/main/java/org/codehaus/plexus/util/cli/CommandLineUtils.java#L348C85-L348C85

That code uses `StringTokenizer` constructed using `new
StringTokenizer(toProcess, "\"\' ", true)`. So yes, Alexander, it does
indeed appear to be using both single quotes and and double quotes as
delimiters.

So next is the question of escaping. The
[documentation](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/StringTokenizer.html)
for `StringTokenizer` says nothing about escaping. I glanced (extremely
quickly) over the source code for `StringTokenizer`, and I don't see it
translating any escape sequences.

Thus if escaping is happening, it would have to be in
`CommandLineUtils.translateCommandline( argsProp )`. And it would be
possible, as it uses the `StringTokenizer` option to return delimiters.
But glancing (again very quickly) over the `CommandLineUtils` code, I
don't see any escaping handling at all.

Thus my conclusion is that the Maven Exec Plugin handles either single
quotes or double quotes as the delimiter, but /does not handle escaping
in either case/. You pick one or the other, and cross your fingers that
the given argument does not contain that delimiter, because there's no
way to escape it ahead of time.

All the discussion of escaping at the Bash/PowerShell/CMD level, while
useful in its own context, has absolutely zero bearing on the issue I
was raising, which was: how to escape a quote at the Maven Exec Plugin
level. The answer seems to be: you can't.

(I glanced over the source code extremely fast, so I could have missed
something. If so please point it out to me!)

Garret

Re: escaping single quote for Exec Maven Plugin `exc.args`

2023-10-15 Thread Garret Wilson

On 10/15/2023 1:31 AM, Alexander Kriegisch wrote:

…
Let us settle on only using double quotes to enclose arguments containing
spaces. Then, we do not need to escape single quotes and can use them
literally. But we do need to escape nested double quotes.

Let's make sure we don't confuse whether we're talking about escaping
occurring at the Bash level, or at the Maven Exec Plugin level. I [made
the
mistake](https://stackoverflow.com/questions/77294556/bash-single-quote-elements-of-array-and-concatenate-using-space?noredirect=1#comment136265886_77294609)
of confusing the two at first.

Just for a moment, forget about Bash/PowerShell/CMD escaping rules. What
are escaping the rules of the Maven Exec Plugin? What does it consider a
delimiter for indicating multiple arguments? Are you saying that Maven
Exec Plugin will accept either single or double quote for delimiter? I'm
not saying it doesn't (I haven't seen the code), but I wouldn't want to
assume it does, either.

For example, let's assume I use whatever escaping rules are appropriate
for my shell, and I do it 100% correctly, so that the Maven Exec Plugin
sees `test "foo\" bar" 'more stuff'`. (I'm using the backtick here to
delimit the string.) The backslash is not part of the Bash-level
escaping—it's literally what the Maven Exec Plugin sees (i.e. I probably
escaped it using `\\\"` or something at the Bash level). How does Maven
Exec Plugin interpret that string? As one argument? As two? As three?

And where is the Maven Exec Plugin documentation for this? The delimiter
rules of the Maven Exec Plugin would be completely independent of the
shell escaping rules. (This is the same as if I passed a single quote
using `'` from XML; once it got to the Maven Exec Plugin in a Maven
property, it would be irrelevant how it was escaped in XML.)

In UNIX-like shells like Bash, a double quote is escaped by a backslash:

-Dexec.args="one \"it's OK\" three"

OK, so following the discussion above, the Maven Exec Plugin will see
the string `one "it's OK" three` (again using a backtick here in this
email as a somewhat arbitrary delimiter for the entire string). Bash is
now out of the picture. How does the Maven Exec Plugin interpret the
string `one "it's OK" three`, and where is that documented?

Garret

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

escaping single quote for Exec Maven Plugin `exc.args`

2023-10-14 Thread Garret Wilson

Here's a fun one for your weekend. As you know from (almost) the 
beginning of time we could invoke a Java application using Maven using 
the Maven Exec Plugin, as in the following (although Maven's `--quiet` 
may be a recent addition):


```bash
mvn exec:java -Dexec.mainClass="com.example.MyApplication" 
-Dexec.args="test" --quiet

```

This passes a single command-line argument to my Java `main()` method 
args array: "test". If I want to pass a string with a space, I put it in 
single quotes, like this:


```bash
mvn exec:java -Dexec.mainClass="com.example.MyApplication" 
-Dexec.args="'foo bar'" --quiet

```

That passes a single string "foo bar" to my application `main()` method 
args array.


Now … what if I want to pass a single string "foo'bar" (note just one 
single quote in the string) as a single string to my `main()` method 
args array? is there some way to escape the single quote? The 
[documention](https://www.mojohaus.org/exec-maven-plugin/java-mojo.html#commandlineArgs) 
doesn't give any clues.


I guess I could look at the Exec Maven Plugin source code (if it's 
available), but that would take half a day and I've already spent half 
of today going down other rabbit holes. So I thought I'd ask here to see 
if anyone knew; otherwise I'll investigate another day when I'm 
refreshed (or just put a temporary note in my Bash script about this 
corner case, but that's not really my style).


Garret


-
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

2023-08-03 Thread Garret Wilson


On 8/3/2023 7:31 AM, Delany wrote:

Quite honestly this is a horrendous abuse of configuration, not to mention
design and security principles, and thoroughly inelegant.


I 100% agree with you on your assessment of the _implementation_. If you 
know of a more elegant implementation without writing a plugin, please 
tell me. Otherwise, it's the fault of Maven to force me to write such an 
ugly kludge. Maven should provide a simple expression language for 
setting properties.


From the point of view of the _interface_ (that is, the user's view—the 
developer using the child POMs), it is very clean and elegant: the 
presence of a single user property determines whether deployment is 
enabled or not.


Once I write a plugin that sets properties based upon an expression, we 
can replace this horrendous implementation while leaving this clean and 
elegant interface exactly as it is.



It brings to mind a Go proverb "A little copying is better than a little
dependency."


This has nothing to do with dependency. Copying boilerplate to disable 
deployment would in no way lower the coupling i.e. it would not reduce 
any dependency in any way.



I've had my say though. If you want to set a property and not have it
inherited in other repos, put it in .\.mvn\maven.config


I don't want to create other files. I want everything in my POM.

Garret


-
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

2023-08-02 Thread Garret Wilson


On 8/2/2023 10:45 PM, Garret Wilson wrote:

…
I won't explain here what's going on; I intend to write a blog post 
about it some day. The end result is that if the 
`com.globalmentor:globalmentor-root` POM is in effect, the 
`maven.deploy.skip` property is set to `true`; for any other 
descendant project, the `maven.deploy.skip` property is set to 
`false`. It works like this pseudocode:


(Sorry, this part of the explanation swapped `true` and `false`; it's 
the opposite of what I said: if the `com.globalmentor:globalmentor-root` 
POM is in effect, the `maven.deploy.skip` property is set to `false`.)


Garret

-
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

2023-08-02 Thread Garret Wilson


On 8/1/2023 7:42 PM, Garret Wilson wrote:

…
Now the child POMs can turn off deployment by simply setting 
`maven.deploy.skip` to `false`, and kill two birds with one stone: 
deployment will be disabled whether the Nexus Staging Plugin or the 
Maven Deploy Plugin was used.


In my previous message I explained how to set up the Nexus Staging 
Plugin so that it can easily be disabled in child projects (along with 
the Maven Build Plugin) using one simple property: `maven.deploy.skip`. 
Now for the next step, the grand finale.


In my original question, I asked if there was a way to keep the Nexus 
Staging Plugin from being inherited in child POMs by default. Really 
"inherited" is an implementation detail. What I really wanted to know is 
if there was to configure the Nexus Staging Plugin to be enabled by 
default in the parent POM, but be disabled by default in the child POM. 
The semantic distinction is subtle, but important; it turns out that 
there's no way to turn off inheritance, but with a few tricks (i.e. 
quite a few very ugly hacks), we can change the default configuration 
based upon whether the plugin is being invoked in the parent POM (here 
`com.globalmentor:globalmentor-root`) or from some child POM.


If Maven supported expressions (oh, if only), this would be rather 
straightforward. Since it doesn't we'll use 
`org.codehaus.mojo:build-helper-maven-plugin` to do things that no one 
should ever have to do (or even consider) in a POM; it looks like this:


```xml

  org.codehaus.mojo
  build-helper-maven-plugin
  
    
  set-is-skip-deploy-false-or-prefixed
  validate
  
    regex-property
  
  
    maven.deploy.skip
_${project.groupId}_${project.artifactId}
^_com\.globalmentor_globalmentor-root$
    false
    false
  
    
    
  set-is-skip-deploy
  initialize
  
    regex-property
  
  
    maven.deploy.skip
    ${maven.deploy.skip}
    ^_.*
    true
    false
  
    
  

```

I won't explain here what's going on; I intend to write a blog post 
about it some day. The end result is that if the 
`com.globalmentor:globalmentor-root` POM is in effect, the 
`maven.deploy.skip` property is set to `true`; for any other descendant 
project, the `maven.deploy.skip` property is set to `false`. It works 
like this pseudocode:


```xml

$("${project.groupId}:${project.artifactId}}"!="com.globalmentor:globalmentor-root)
```

(Wouldn't it be nice to have expressions like this.)

I succeeded in pulling off effectively what I asked for. But in reality 
I would like the `maven.deploy.skip` property to be determined by 
whether `nexus.host` is set to some value, and I want `nexus.host` to be 
set to a default value in `com.globalmentor:globalmentor-root` but not 
in child POMs. But that sort of two-layered logic (although simple if 
Maven supported expressions) is too much for the ugly kludge I'm using 
(and more than my mind wants to deal with).


So in the end I settled for a sort of compromise: I made the value of 
`maven.deploy.skip` dependent on whether `nexus.host` is set to a 
non-empty string. Thus the Nexus Staging Plugin is enabled by default, 
but in any child POM I can easily turn off deployment by setting the 
`nexus.host` to the empty string, like this:


```xml

  
```

This automatically turns off `maven.deploy.skip` via this ugly kludge:

```xml

  org.codehaus.mojo
  build-helper-maven-plugin
  
    
  set-is-skip-deploy-true-or-prefixed
  validate
  
    regex-property
  
  
    maven.deploy.skip
    _${nexus.host}
    ^_$
    true
    false
  
    
    
  set-is-skip-deploy
  initialize
  
    regex-property
  
  
    maven.deploy.skip
    ${maven.deploy.skip}
    ^_.*
    false
    false
  
    
  

```

I'll live with this for now. I'll probably wind up writing a Maven 
set-property-from-expression plugin at some point, when I can't digest 
this sort of nasty workaround any more.


Garret


-
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

2023-08-01 Thread Garret Wilson


On 7/30/2023 3:28 PM, Garret Wilson wrote:
… I also see that there is a `skipNexusStagingDeployMojo`, but that 
appears to be neither a configuration property nor a user property, 
but only a "plugin flag" which is "passed in from the CLI" using `-D`. 
Is there a "skip" configuration property for the Nexus Staging Maven 
Plugin ?


Answering my own question: yes, the `skipNexusStagingDeployMojo` "flag" 
indeed seems to work as a "configuration property". Setting this to 
`true` disables the entire Nexus Staging Plugin, and the default Maven 
Deploy Plugin doesn't seem to run either (because I assume that the 
Nexus Staging Plugin has disabled it anyway).


> [INFO] Skipping Nexus Staging Deploy Mojo at user's demand.

If I were to remove the Nexus Staging Plugin, I _assume_ that the Maven 
Deploy Plugin would take effect, in which case I would need to set its 
`skip` configuration property to `true` (or set the `maven.deploy.skip` 
user property).


This simple answer is a big step forward, but it's only halfway to 
easily turning this off in the child POM. (Yes, I want things to be 
easier than redeclaring a plugin configuration in the child POM.) The 
next "obvious" step is to create a user property to turn off the Nexus 
Staging Plugin. And we already have one—the `maven.deploy.skip` user 
property for the Maven Deploy Plugin! So all we have to do is add this 
to the Nexus Staging Plugin:


```xml
${maven.deploy.skip}

```

Now the child POMs can turn off deployment by simply setting 
`maven.deploy.skip` to `false`, and kill two birds with one stone: 
deployment will be disabled whether the Nexus Staging Plugin or the 
Maven Deploy Plugin was used.


See, things don't have to be difficult.

I have one more tweak to make things even easier and protect even more 
against accidental deployment. I'll explain how in a separate message.


Best,

Garret


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

Re: How to force Maven to put a dependency on the module-path?

2023-08-01 Thread Garret Wilson


On 7/26/2023 1:42 PM, Martin Desruisseaux wrote:
… If a dependency is on the classpath, then the dependency is loaded 
as an unnamed module, its "module-info" file is ignored and the 
services that it contains are not discovered.


Can you elaborate on the last point a little more? I haven't modularized 
my core libraries yet, and want to know how they would work with 
non-modularized applications.


You say that if the modularized library is put on the classpath, its 
services are not discovered. But wouldn't normal pre-module-era 
classpath-based service discovery still work via the `META-INF/services` 
configurations in the library JAR files? Please clarify what won't work 
if I modularize my core libraries, which contain services to be 
discovered, and I try to use that with a non-modularized application.


Thanks,

Garret


-
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

2023-07-31 Thread Garret Wilson


On 7/31/2023 1:27 PM, 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".


This question was never about "anonymous uploads" or "random repos". The 
parent POM specifies a specific server, for which specific credentials 
are specified in `settings.xml`. The issue is that this configuration is 
inherited, so this question was simply how to elegantly disable this 
behavior in child POMs, to prevent accidentally deploying a child 
project to the same server with the same credentials as inherited from 
the parent POM.


Your `none` idea is probably the best I'm going to get, 
thanks. I'll add appropriate tricks to make that more easily configured 
via a property, which I already know how to do.


Garret


-
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

2023-07-31 Thread Garret Wilson


On 7/31/2023 1:02 PM, Garret Wilson wrote:

…
Let me confirm something: if I disable the Nexus Staging Maven Plugin 
by using `none` in a child POM, what will happen when a 
developer types `mvn deploy`? Nothing? I only ask because Tamás had 
mentioned the Maven Deploy Plugin. But I'm looking at the latest 
[super 
POM](https://maven.apache.org/ref/3.9.3/maven-model-builder/super-pom.html), 
and it looks like Maven Deploy Plugin is only activated in the 
`performRelease` profile (which is to be removed anyway).


Oops, nope, it looks like Maven somewhere internally (not in the Super 
POM) still associates the Maven Deploy Plugin with the `deploy` phase: 
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#default-lifecycle-bindings-packaging-ejb-ejb3-jar-par-rar-war


I guess if I want _all_ deployment disabled (I'll replace it with 
something more interesting later—that's a whole different topic) in a 
child POM, I'll need to set `none` for the Nexus Staging 
Maven Plugin, and set `true` for the Maven Deploy Plugin.


(I see that Delany's response came as I was typing this; I'll still send 
it because of the documentation link and the summary.)


Garret


-
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

2023-07-31 Thread Garret Wilson


On 7/31/2023 3:07 AM, Delany wrote:

Perhaps you're getting confused because you conflate 2 issues:
… prevent general configuration like  from being inherited.
… preventing plugin configuration from being inherited.


I do not conflate them—I do not think they are the same thing. I said 
they are both similar in one aspect: they have to be defined in order to 
publish the parent POM itself, but they semantically may not apply to 
projects that _use_ the parent POM, and thus may not be desired to be 
inherited.


But I don't want to get off-track; perhaps it was unwise to even mention 
the `` issue and risk going down a different rabbit hole. I'll 
stick to the plugin configuration inheritance topic.



The second, to disable executions by default, just configure the phase to
none. Do this if the plugin/goal lacks a  parameter.


Ah, I had forgotten about the `none` trick—thanks for 
reminding me, Delany.


Let me confirm something: if I disable the Nexus Staging Maven Plugin by 
using `none` in a child POM, what will happen when a 
developer types `mvn deploy`? Nothing? I only ask because Tamás had 
mentioned the Maven Deploy Plugin. But I'm looking at the latest [super 
POM](https://maven.apache.org/ref/3.9.3/maven-model-builder/super-pom.html), 
and it looks like Maven Deploy Plugin is only activated in the 
`performRelease` profile (which is to be removed anyway).


So if using `none` with the Nexus Staging Maven Plugin 
completely disables all staging and deployment, that may be the easiest 
way to disable it in the child POM. Thanks again for the tip.


Garret

-
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

2023-07-30 Thread Garret Wilson

On 7/30/2023 9:18 PM, Nick Stolwijk wrote:

I took a quick look at the Maven-Nexus-plugin and there is an option to
disable it (skipNexusStagingDeployMojo), so I would start there.

I in fact did start there. I don't know if you happened to read this 
part of my question which started this thread:

> … let's instead find an easy way to turn it off. I don't see in the 
documentation (see link above) that there's even
> a "skip" property. Is there? I see that the Maven Deploy Plugin has 
such a feature.
> I also see that there is a `skipNexusStagingDeployMojo`, but that 
appears to be neither a configuration property
> nor a user property, but only a "plugin flag" which is "passed in 
from the CLI" using `-D`.
> Is there a "skip" configuration property for the Nexus Staging Maven 
Plugin ?

So I guess I'm back to where I started.

Garret

-
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

2023-07-30 Thread Garret Wilson


How is the best way you would recommend to turn off publishing in parent B?

Garret

On 7/30/2023 8:47 PM, Nick Stolwijk wrote:

In that case I would publish your parent with all the Good Stuff (parent A)
in the central repository, and have a second parent inheriting Parent A
where publishing is turned off. So your super secret, multi gazillion
project can inherit from parent B and so no publishing is going on, unless
they turn on the maven-flatten-plugin and a publish plugin.

Nick Stolwijk

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

Lord Baden-Powell


On Mon, 31 Jul 2023 at 01:30, Garret Wilson  wrote:


On 7/30/2023 8:16 PM, Nils Breunese wrote:

…
Can I ask why you publish this root POM as a public artifact to Maven

Central?

1. To be a good open-source citizen and help others with all the goodies
this POM provides (many of them which should be in Maven by default but
are not).

2. To provide a standard baseline for expectations for all of our
projects (e.g. build properties that are populated), including our
open-source projects and our hypothetical super-secret
multi-million-dollar projects.


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

But the error lies in conflating the two conceptually.

The child project is what is super-secret and multi-gazillion dollars
worth. The parent project is just a tool; it is not super-secret nor
worth multi-gazillion dollars.

You realize that Maven comes with its own super POM, right? So we could
ask the same question: if I'm building a super-secret gazillion-dollar
project, might not it be safer to find out how to disable Maven's own
super POM? But of course we know that's a silly question.

One should have nothing at all to with the other. The super POM just
sets up some common properties that everyone can use. My root POM just
sets up some common properties that everyone can use. I should be able
to publish my root POM and easily disable publishing for its children.

This is one of Maven's drawbacks: inheriting too much from the POM. For
example if you publish a parent POM that has one license (e.g. Apache
2.0), suddenly all its children inherit the same license (although most
people aren't aware of this) without specific overriding. See my Stack
Overflow question [Publish open-source Maven parent POM without
inheriting ``](https://stackoverflow.com/q/73239332) and
[MNG-7562](https://issues.apache.org/jira/browse/MNG-7562).

The central issue in both cases is that the Maven designers in general
seemed not to have realized the need to distinguish between "information
related to publication of this POM" with "information that is to be
inherited to child POMs".

Garret


-
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: elegant way to disable Nexus staging/deployment in child POMs

2023-07-30 Thread Garret Wilson


On 7/30/2023 8:16 PM, Nils Breunese wrote:

…
Can I ask why you publish this root POM as a public artifact to Maven Central?


1. To be a good open-source citizen and help others with all the goodies 
this POM provides (many of them which should be in Maven by default but 
are not).


2. To provide a standard baseline for expectations for all of our 
projects (e.g. build properties that are populated), including our 
open-source projects and our hypothetical super-secret 
multi-million-dollar projects.



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


But the error lies in conflating the two conceptually.

The child project is what is super-secret and multi-gazillion dollars 
worth. The parent project is just a tool; it is not super-secret nor 
worth multi-gazillion dollars.


You realize that Maven comes with its own super POM, right? So we could 
ask the same question: if I'm building a super-secret gazillion-dollar 
project, might not it be safer to find out how to disable Maven's own 
super POM? But of course we know that's a silly question.


One should have nothing at all to with the other. The super POM just 
sets up some common properties that everyone can use. My root POM just 
sets up some common properties that everyone can use. I should be able 
to publish my root POM and easily disable publishing for its children.


This is one of Maven's drawbacks: inheriting too much from the POM. For 
example if you publish a parent POM that has one license (e.g. Apache 
2.0), suddenly all its children inherit the same license (although most 
people aren't aware of this) without specific overriding. See my Stack 
Overflow question [Publish open-source Maven parent POM without 
inheriting ``](https://stackoverflow.com/q/73239332) and 
[MNG-7562](https://issues.apache.org/jira/browse/MNG-7562).


The central issue in both cases is that the Maven designers in general 
seemed not to have realized the need to distinguish between "information 
related to publication of this POM" with "information that is to be 
inherited to child POMs".


Garret


-
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

2023-07-30 Thread Garret Wilson


On 7/30/2023 7:34 PM, Nick Stolwijk wrote:

I am missing the purpose of publishing the parent pom. Is it because other
projects can inherit of it,


Yes.


or is it because your own projects (that you
want to be published) are inherited from it?


Yes.


In the second case, you can use the maven-flatten-plugin to have the
published projects not be dependent on your parent project. In that case
you can use the parent projects  to setup the
configuration and activate it in the child modules in the build section. If
you enable the maven-flatten-plugin in the parent project for each child
project there is no project inheritance anymore in the published artifacts,
so there is no need to publish your parent pom.


I confess I don't know much about the Maven Flatten Plugin, but it 
sounds suspiciously like the Maven Shade Plugin, which Seemed Like A 
Good Idea At The Time To Muck With Everything, but from much personal 
experience the details bring nothing but pain and suffering.


So if I flatten everything, how do I publish a BOM of my multimodule 
aggregate subprojects without bringing in project-specific dependencies 
that shouldn't go in the BOM?


I don't want to dismiss suggestions too quickly if I don't fully 
understand them, but sincerely, just the idea sound like it would bring 
lots of tears for years and years.


Garret


-
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

2023-07-30 Thread Garret Wilson


On 7/30/2023 6:32 PM, Tamás Cservenák wrote:

There is no need for another plugin... well, let me explain:
all the "vanilla" plugins of Maven (install, deploy, release) support
everything that aforementioned plugin does: install at end, deploy at end,
stage/deploy, there is ONLY two things they cannot do: "close" and
"release" (the staging repo).


Tamás, thanks again for this explanation. I have never drilled down in 
to the deployment process.


I'm reading the [Nexus Staging Maven Plugin 
documentation](https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md), 
and if I'm understanding it correctly, this plugin actually somehow 
_disables_ the Maven Deploy Plugin in Maven 3.x?


So if I were to put the Nexus Staging Maven Plugin into a separate 
profile, and then run `mvn deploy` without specifying that profile, does 
that mean that by default the Maven Deploy Plugin would kick in 
automatically and still try to upload my artifacts somewhere? Where 
would it try to upload them to?


Is there some documentation on deploying my artifacts to Maven Central 
without using the Nexus Maven Plugin?


I configured all this deployment stuff probably 10 years ago. I'm going 
back to my notes, and it looks like here are the instructions, straight 
from Sonatype, for [Deploying to OSSRH with Apache 
Maven](https://central.sonatype.org/publish/publish-maven/#nexus-staging-maven-plugin-for-deployment-and-release). 
There it's pretty clear:


> The Nexus Staging Maven Plugin is the recommended way to deploy your 
components to OSSRH and release them to the Central Repository.


It appears that Sonatype hasn't been informed that the Nexus Staging 
Plugin is end-of-life, shouldn't be used, and won't work in Maven 4. :)


Garret


-
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

2023-07-30 Thread Garret Wilson


I think we'll have to "agree to disagree" on this one.

But I'll note that by following the same logic presented below, 
CloudFormation and Terraform would require the developer to log into the 
AWS console to finalize a deployment. That similarly would be 
unacceptable to me.


Thanks for pointing out that this plugin is end-of-life and explaining 
the implications of dropping it.


Garret

On 7/30/2023 6:44 PM, Tamás Cservenák wrote:

Well, I disagree:
The App UI you are staging to will show you:
- who staged,
- what is staged
- in case or error (ie. signature mismatch or checksum mismatch) where are
the problems
- etc

Is not prone to errors, as you do not modify content at all by doing that
(Maven did deliver it already), reproducibility really depends only on your
build, not this 3rd party service (they blindly accepts bytes and just
checks some rules "ok"/"not ok"), as for security you already provided
credentials while staging.

Given the "stability" history of oss or s01, I have to say that it is even
_desirable_ to be able to use UI for these steps, as otherwise you are just
"burning" versions (failed releases) for reasons totally unrelated to
Maven, but for some 3rd party service that provides you "way" to get
something to Central.

Unless... we talk about some private Nx instance? Or Sonatype oss one? As
in that case scripting would work for it.
After all, this is proprietary software (they call it "oss" but is more
like "free"), with its own proprietary REST API...

T

On Sun, Jul 30, 2023 at 11:37 PM Garret Wilson 
wrote:


On 7/30/2023 6:32 PM, Tamás Cservenák wrote:

There is no need for another plugin... well, let me explain:
all the "vanilla" plugins of Maven (install, deploy, release) support
everything that aforementioned plugin does: install at end, deploy at

end,

stage/deploy, there is ONLY two things they cannot do: "close" and
"release" (the staging repo).

For those two things, you'd need to use the browser, navigate to oss or

s01

server, log in, and using Nexus UI close or release your staging

repository.

If this is acceptable to you, you should just drop the use of that

plugin.

Requiring me to use my browser and log into a site and muck around with
a mouse just to release software is not acceptable.

That might have been acceptable in 2003.

We just don't do things like that nowadays. It's not just for
convenience. It's bad practice, prone to errors, hard to reproduce,
introduces security issues, unwieldy to maintain, and a general
infrastructure-as-code  anti-pattern for 100 reasons, which you can
probably recite as well as I can.

Garret


-
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: elegant way to disable Nexus staging/deployment in child POMs

2023-07-30 Thread Garret Wilson


On 7/30/2023 6:32 PM, Tamás Cservenák wrote:

There is no need for another plugin... well, let me explain:
all the "vanilla" plugins of Maven (install, deploy, release) support
everything that aforementioned plugin does: install at end, deploy at end,
stage/deploy, there is ONLY two things they cannot do: "close" and
"release" (the staging repo).

For those two things, you'd need to use the browser, navigate to oss or s01
server, log in, and using Nexus UI close or release your staging repository.

If this is acceptable to you, you should just drop the use of that plugin.


Requiring me to use my browser and log into a site and muck around with 
a mouse just to release software is not acceptable.


That might have been acceptable in 2003.

We just don't do things like that nowadays. It's not just for 
convenience. It's bad practice, prone to errors, hard to reproduce, 
introduces security issues, unwieldy to maintain, and a general 
infrastructure-as-code  anti-pattern for 100 reasons, which you can 
probably recite as well as I can.


Garret


-
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

2023-07-30 Thread Garret Wilson

Oh, I'll gladly switch to another plugin. I can just change out the
whole inheritance tree—no problem. Goodness knows that this plugin has a
bunch of problems (e.g. NEXUS-26993 and NEXUS-31301, which tickets don't
seem to be visible anymore).

I thought sure I asked about this (probably in NEXUS-26993 and/or
NEXUS-31301); I don't remember the response exactly, but I thought the
new plugin was only for some special customers.

What should I be using instead, and where is its documentation? I want
to use the latest and greatest!

Garret

On 7/30/2023 4:54 PM, Tamás Cservenák wrote:

And how about not using this plugin? Even it's maintainer dropped it, is
EOL. Furthermore, things this plugin does means is (or is to be) unusable
with Maven4. So is a dead end.

A new project should not start using it, really.

Hth
T

On Sun, Jul 30, 2023, 20:29 Garret Wilson wrote:

I have a "root" POM which I use as the inheritance ancestor of all my
projects: https://github.com/globalmentor/globalmentor-root

By default it's configured to use the [Nexus Staging Maven
Plugin](
https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md).

It even has a handy `nexus.host` property to define the Nexus server
(because Sonatype actually puts accounts on separate old-school hosts,
but I digress).

The catch-22 here is that I need this configuration to be turned on for
me to publish this POM to Maven Central, yet there are descendant
projects that use it that I never want to publish to Maven Central. I
don't want this publishing feature turned on by default in child
projects. I would prefer to have a flag that I simply turn on in child
projects (i.e. opt-in) that are to be made public. Any way to have the
Nexus Staging Maven Plugin enabled in the POM itself for publishing to
Maven Central, but have it disabled by default for inherited problems?

I'm guessing the answer is "no", so let's instead find an easy way to
turn it off. I don't see in the documentation (see link above) that
there's even a "skip" property. Is there? I see that the Maven Deploy
Plugin has such a feature. I also see that there is a
`skipNexusStagingDeployMojo`, but that appears to be neither a
configuration property nor a user property, but only a "plugin flag"
which is "passed in from the CLI" using `-D`. Is there a "skip"
configuration property for the Nexus Staging Maven Plugin ?

Does anybody know of a better approach for easily disabling publishing
to Maven Central in an inheriting project?

Garret

P.S. I'm debating whether this question would be better published on
Stack Overflow, but in my experience it seems that the Maven experts
seem to respond here more than on Stack Overflow.

-
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

2023-07-30 Thread Garret Wilson


On 7/30/2023 4:37 PM, Mantas Gridinas wrote:

Sounds like a job for profiles, …


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.



Another idea is to have 2 poms: one for your root, the other for module
definitions, and latter would use relative parent for the former.


Hidden somewhere in your answer is the assumption that I do not publish 
this second POM. So now I have a sharing issue—developers can no longer 
use this second POM from Maven Central, and I have to have some other 
distribution mechanism.


With that in mind, I could just simply not publish the root POM to begin 
with. Problem solved. Except that the problem is not solved. The problem 
is how I publish a POM and have its children not have the publishing 
enabled by default. Your answer, boiled down to its essence, says, "just 
don't publish the root POM"—but publishing the root POM is part of the 
problem statement, and what makes the problem difficult.



Third one is to fiddle with -m/--modules flag by telling maven to only
include modules in the reactor provided by that flag.


I was never too good with the violin. I would prefer not to fiddle with 
things. I also don't want to use CLI flags. I simply want to have a 
child POM work normally, with publishing disabled unless I add something 
simple to the child POM itself.


Garret


-
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

2023-07-30 Thread Garret Wilson


On 7/30/2023 4:00 PM, Delany wrote:

What happens if you add this to the pluginManagement/plugin section?

false

Delany



Delany, I think you are referring to the `` tag for build 
plugins documented here: 
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_.3Cinherited.3E_Tag_In_Build_Plugins


Thanks for pointing out this option. It's good to know this exists.

But wouldn't that prevent the entire configuration from being inherited? 
Look at the [source code of the 
POM](https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml) 
I linked to. It has this configuration:


```

  ossrh
  https://${nexus.host}/
  true

```

If I don't inherit the configuration, then I have to duplicate that 
boilerplate int he child POMs. I _want_ to inherit the configuration. I 
just don't want it to be enabled by default. That is two very different 
things.


Garret


-
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

2023-07-30 Thread Garret Wilson


On 7/30/2023 3:45 PM, Thomas Broyer wrote:

The easiest way to opt-in is to configure the plugin in 
of the parent POM, and then only "apply" to chosen projects by declaring
the plugin in the  (only needs the groupId and artifactId
then)


Let me make sure I'm understanding what you're suggesting:

1. Configure the plugin in `` in the root POM.

2. Do _not_ add the plugin to the `` section in the root 
POM.


Is that what you are proposing?

So then how do I publish the root POM itself to Maven Central? (That was 
the "catch-22" part in the description.)


Garret


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

elegant way to disable Nexus staging/deployment in child POMs

2023-07-30 Thread Garret Wilson

I have a "root" POM which I use as the inheritance ancestor of all my
projects: https://github.com/globalmentor/globalmentor-root

By default it's configured to use the [Nexus Staging Maven
Plugin](https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md).
It even has a handy `nexus.host` property to define the Nexus server
(because Sonatype actually puts accounts on separate old-school hosts,
but I digress).

Does anybody know of a better approach for easily disabling publishing
to Maven Central in an inheriting project?

Garret

P.S. I'm debating whether this question would be better published on
Stack Overflow, but in my experience it seems that the Maven experts
seem to respond here more than on Stack Overflow.

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

Re: [DISCUSSION] Multi platform deploys/releases

2023-06-25 Thread Garret Wilson


On 6/25/2023 2:10 PM, Tamás Cservenák wrote:

Multiple times come up on ML questions from users about "multi platform"
deploys/releases, where, AFAIK, some (usually) OS platform
dependant (usually native binary), comes to play.
…
- how are people doing it today?


For my projects I've spent years refining the GlobalMentor "Root POM" at 
https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml . If 
your POM inherits from this POM, then you can define _a single property_ 
`exe.main.class` in your POM, and the build will automatically generate 
the following (example assumes your project is named `my-cli`):


* A `my-cli-1.2.3-exe.jar` (which you can execute using `java -jar …`).
* A Linux self-executing script named `my-cli` (the executable JAR with 
a Bash script starter embedded).

* A Windows executable `my-cli.exe`.

Furthermore if you specify `-P publish` for the profile when building, 
it will also generate a `my-cli-1.2.3-bin.zip` file containing the 
executables mentioned above, with executable bits set and everything, 
for distribution.


Even this is not a complete solution; it still requires one to 1) 
install Java, and 2) know what to do with an executable. (See the 
[Install Datimprint CLI 
instructions](https://www.jordial.com/software/datimprint/install), for 
example.)


Still you can not imagine the pain I had to go through just to get this 
much automation.


1. Maven doesn't really support expressions, so I had to create hacks on 
top of kludges to get defining `exe.main.class` to work as a "toggle" to 
turn other plugins on and off. I plan on writing a blog entry explaining 
this one day, but for now just look for the multiple sequential regexes 
for e.g. `_\$\{exe.main.class\}`. Yes, it is mind-bending.


2. In addition Maven's issue with undefined order of plugin execution 
when defined in parent POMs was another huge roadblock (e.g. 
[MNG-5799](https://issues.apache.org/jira/browse/MNG-5799) to pick one 
random ticket out of many, requiring me to spread plugin executions 
across multiple phases just to get some sort of deterministic order 
(e.g. so I don't try to zip up the executables before they are created, 
and I don't try to create the executables before the executable JAR is 
created, etc.).


3. And speaking of assembly, I had to play even more tricks to get an 
assembly defined in a parent POM, because the Maven Assembly Plugin 
doesn't allow in-POM definitions of the assembly descriptor. (I can't 
inherit a separate assembly descriptor defined in a parent POM, and I 
need to have the assembly descriptor do property interpolation, etc.)  I 
actually use a hack in which the Antrun  Plugin _generates_ the assembly 
descriptor at just the right time (again, walking a tightrope just to 
get this to all fall in place in the right sequence in the descendant POM).


The next step which I haven't yet taken is to have an installer for this 
EXE/script/JAR, working across platforms. Supposedly JPackage addresses 
this, but I soon realized that it's tied to the platform you're building 
your project on, which is a non-starter—I don't want to set up build 
separate pipelines for each separate targeted platform. I have thought 
about seeing if I can integrate Docker into my Maven build to get around 
this, but I haven't had time to research that further.

- what can Maven do to help more (if not fully support) this problem?


As explained with my harrowing hacks above, before we even get to 
cross-platform targeted builds, there are a few fundamental Maven blind 
spots that need to be addressed: 1) expression support, 2) deterministic 
plugin execution ordering even when one plugin has multiple executions 
defined in the same phase across parent and child POMs, and 3) in-POM 
configuration of all plugins.  (Kudos to the Versions Maven Plugin which 
finally implemented this in 
[#684](https://github.com/mojohaus/versions/issues/684).) I really 
should not have had to take years and this many hacks and workaround 
just to generate a few JARs and zip them up, based upon a property being 
defined.


Otherwise it seems to me that more and more things are using Docker, and 
Docker may be the only way to generate multi-platform targeted binaries 
under some situations, so I guess increasing Docker interoperability may 
be a general theme. (Maven may be there already—I confess I haven't had 
a chance to do much with Docker from Maven other than generating images 
using a plugin, and that's working with no problems so far, as long as 
Docker is installed and running.)


Garret

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

Re: BOM files referencing optional dependencies

2023-06-17 Thread Garret Wilson


Hi, Ceki.

My understanding is that, yes, if they are part of the main library 
(i.e. not transitive dependencies from some other library), then they 
should also be included in the BOM.


The BOM is usually imported under the `` section, 
which is simply the place where you are managing which versions to use 
for artifacts. This section doesn't actually say the project is using 
any particular artifact—it's simply nailing down the versions.


Thus I would say the idea of "optional" doesn't even apply to the 
`` section and to BOMs. Or to put it another way, 
at the time you import a BOM into the `` section, 
/everything/ in the BOM is optional until it is declared to be actually 
used separately in the actual `` section of the POM or one 
of its descendants.


Garret

On 6/17/2023 12:32 PM, Ceki Gülcü wrote:

Hello,

Is it considered good practice to reference optional dependencies in BOM
files?

Re: improving the Maven BOM pattern

2023-06-14 Thread Garret Wilson

On 6/14/2023 5:53 PM, Gary Gregory wrote:

I am wondering if you've looked at the CycloneDx and SPDX Maven plugins?

These two seem to be the most used ATM for SBOMs.

Gary

I had never heard of these plugins or of SBOMs. I did a quick bit of 
research; according to [How to create SBOMs in Java with Maven and 
Gradle](https://snyk.io/blog/create-sboms-java-maven-gradle/):

> But be careful to not confuse an SBOM with Maven's Bill Of Materials 
(BOM). In Maven, a BOM is a special kind of POM file where we can 
centralize dependencies for an application. In most cases, these 
dependencies work well together and should be used as a set, like we see 
in BOMs used in Spring.

> An SBOM is something you create next to your application, so any user 
or client has a uniform way to find out what your application is using 
under the hood.

So an SBOM seems to be different than the Maven BOM I was talking about, 
with a different purpose. But thanks for the pointer—always nice to 
learn about new things.

Garret

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

Re: improving the Maven BOM pattern

2023-06-14 Thread Garret Wilson


The file tree didn't go across the list so well. Here's another try below:

On 6/14/2023 4:05 PM, Garret Wilson wrote:

…

Over the years I've changed how I define "Bill of Material" POMs for 
my large, aggregated projects. Recently I've settled on a pattern 
which I feel is a refinement of the official Maven approach 
<https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms> 
for putting together a BOM. I've described the technique in my blog 
post I published today: /Improving the Maven Bill of Materials (BOM) 
Pattern/ 
<https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern>. 
Here's a summary.


Assuming we have a project `com.example:…` with aggregated subprojects 
`com.example:foo` and `com.example:bar`, my technique uses the 
following directory structure:


pom.xml
parent-pom.xml
├── foo/
│   └── pom.xml
└── bar/
    └── pom.xml


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

improving the Maven BOM pattern

2023-06-14 Thread Garret Wilson

Hi, everyone. I understand this list to be a general forum for Apache
Maven users, so as such I'm sharing some ideas I've had related to BOMs.

Over the years I've changed how I define "Bill of Material" POMs for my
large, aggregated projects. Recently I've settled on a pattern which I
feel is a refinement of the official Maven approach

for putting together a BOM. I've described the technique in my blog post
I published today: /Improving the Maven Bill of Materials (BOM) Pattern/
.
Here's a summary.

Assuming we have a project `com.example:…` with aggregated subprojects
`com.example:foo` and `com.example:bar`, my technique uses the following
directory structure:

|pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └── pom.xml|

Interestingly the top-level BOM aggregates all three POMs: the two
submodule POMs as well as `parent-pom.xml` in the project root
directory. The two submodules `foo` and `bar` use `parent-pom.xml` as
their parent.

I see this bringing a couple of benefits over the official approach in
the documentation:

* Aggregated modules are easy to find—in the top-level POM where they
logically should be.
* Other project dependencies and configurations are located nearby, in
the `parent-pom.xml` file in the same project root directory as the
BOM, not relegated to a separate subdirectory.

The post goes into much more detail explaining the differences, with
example of the POM contents.

I'd be interested in feedback on this technique if you have any
comments—especially if you find a flaw in this approach.

Best,

Garret

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

2023-05-25 Thread Garret Wilson

Good morning and thanks for such an interesting history of Maven 
evolution, Tamás. See below on discussion for next troubleshooting steps:


On 5/25/2023 2:23 AM, Tamás Cservenák wrote:

…
I really cannot tell who or what (my guess) corrupted the "update 
check" related files.


This is the part of the response that confuses me. What "'update check' 
related files" are we talking about? I infer from the discussion that 
nobody knows the "exact" file. But for the artifact 
`com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`, aren't we 
pretty sure that whatever is "corrupted" is in the 
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin` 
directory right? This is an honest question: is there any place else 
that the Versions Maven Plugin stack could potentially be using to know 
if it should check Maven central?


And if 
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin` 
is the only place that could be affecting this problem, well … there are 
not a lot of files in that directory.


And now that we have a better idea of what Versions Maven Plugin is 
really using to check for updates (and isn't as simple as we thought 
before), doesn't the source code give us some idea about what files it 
is checking? You mentioned m2e and the like, and sure, I understand that 
they all potentially use different things and can potentially change 
different files in different ways. But in Maven 3.9.1 when I execute 
`mvn versions:display-plugin-updates`, I am not using m2e—I am only use 
a single tool that we have the source code to and undoubtedly some of 
you even wrote part of. And we have no idea what particular file the 
current Versions Maven Plugin stack would be checking to see if the 
cache is stale? That's the part I honestly am not understanding.


As it was said before, your best bet is to "nuke" your local 
repository, as it is really just a cache and should be considered as such.


But what does that solve? That gets me past an issue that I have right 
now, this morning. But what about tomorrow? How long will I know that my 
brand new cache is up-to-date for? A day? A week? Next month, can I 
trust Versions Maven Plugin? I have over 25,000 files in my 
`~/.m2/repository`. When might one of the new ones get "stuck" again? 
Should I create a script that blows away my `~/.m2/repository` every 
morning when my computer boots up?


And here's the larger issue: this is not just about me. Think about all 
the developers out there using Versions Maven Plugin. How many of them 
are getting stale information and don't even know it? Should we add a 
feature to Maven to blow away `~/.m2/repository` the first time it is 
run ever 24 hours? That wasn't a serious suggestion; I'm just trying to 
make a point: until we know how prevalent it is (which we won't know 
until we know more about what exactly is happening), "nuking" 
`~/.m2/repository` doesn't "solve" anything.


Now I'm happy to "nuke" my `~/.m2/repository` if I do it in a way that 
gets us closer to understanding what the problem is here. As I mentioned 
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin` 
seriously does not _have_ a lot of files. And the files are pretty 
simple—it shouldn't be hard to see if they are "corrupted". Let me go 
through what I (just from looking at the files) would think would be 
candidates for being the problem:


* `maven-metadata.xml`: This file is missing! The debug output says, 
"Could not find metadata 
com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml 
in local (C:\Users\user\.m2\repository)". And indeed this file is not 
there. Could this be related?


* `resolver-status.properties`: This file contains a single line: 
`central.maven-metadata-central.xml.lastUpdated=1662676475074`. 
Interpreting the value as a Unix epoch-based timestamp, this indicates a 
date of 2022-09-08, which matches the `Thu Sep 08 15:34:35 PDT 2022` in 
the comments


* `maven-metadata-central.xml`: This file has `2.1.2`, 
`2.1.2`, a list of versions ending in 
`2.1.2`, and finally a 
`2021081806`. At first I interpreted this 
date as a Unix epoch-based timestamp, which would indicate a date far 
into the future. But an [answer on Stack 
Overflow](https://stackoverflow.com/a/76303661) indicated my assumption 
was incorrect—that this is instead a MMDD… type string timestamp, 
indicating 2021-08-18. Oddly this date does not match the time in 
`resolver-status.properties`. Even stranger, the file system timestamp 
of `maven-metadata-central.xml` is 2022-09-08, which _does_ match the 
date in `resolver-status.properties`, and in fact also matches the file 
system timestamp of `maven-metadata-central.xml.sha1`!! It seems odd 
that the checksum file for `maven-metadata-central.xml` would have a 
file system timestamp of 2022-09-08, the `resolver-status.properties` 
file would have a file system timestamp

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

2023-05-24 Thread Garret Wilson

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.akathist.maven.plugins.launch4j:launch4j-maven-plugin].effectiveVersion=2.1.3
[DEBUG]
[com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].specified=true
…
```

This debug information seems to be saying that it can't find
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata.xml`.

And in fact that file does not exist! Instead I have
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata-central.xml`.

(I don't know what the differences are.)

The more ominous line is this one:

  > `[DEBUG] Skipped remote request for
com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml,

locally cached metadata up-to-date`

W

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

2023-05-24 Thread Garret Wilson

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.akathist.maven.plugins.launch4j:launch4j-maven-plugin].effectiveVersion=2.1.3
[DEBUG] 
[com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].specified=true

…
```

This debug information seems to be saying that it can't find 
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata.xml`. 
And in fact that file does not exist! Instead I have 
`C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata-central.xml`. 
(I don't know what the differences are.)


The more ominous line is this one:

> `[DEBUG] Skipped remote request for 
com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml, 
locally cached metadata up-to-date`


What might be causing Maven Resolver on my machine to get "stuck" at an 
earlier point in time, and/or to skip checking Maven Central altogether 
for newer versions of many plugins?


Garret Wilson


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

39 matches

Mail list logo