Re: Terminology proposal: "Maven module" -> "Maven sub-project"

2024-08-17 Thread Matthias Bünger 

I personally associate "build" with (hmm how to describe it) once
"instance" or execution of a Maven project or with a pipeline run by my
CI server.

I think the term project is fine as the POM also stands for "project
object model" according to the POM reference, so "multi-subproject
projects" feels unnatural atm the moment but I guess that's just a
matter of time until it settles


Am 17.08.2024 um 12:58 schrieb Guillaume Nodet:

What about "multi-project build" or "single-project build" ?
The "multi-module-project" is exactly one I'd like to get rid of, as
"project" here is very ambiguous imho.

Le sam. 17 août 2024 à 10:57, Matthias Bünger
 a écrit :

+0 I'm open to this change, but can lalso live without it, but I get the
idea and the aspects behind it.

To add to the discussion about names/phrases:

As of now we have "multi-module-project" and "single-module-project".
"(multi-)subproject-project" is as clear to me as, and "single-project"
is a as goot as "single-module-project" in my case.

Greetings

Matthias

Am 05.08.2024 um 14:14 schrieb Martin Desruisseaux:

In order to avoid confusion between "Maven module" and "Java module",
I suggest to update documentation for using "Maven sub-project"
instead of "Maven module". However, the  XML elements in the
POM would be unchanged for compatibility reason. There is apparently
not so many places in the documentation that need to be updated. The
ones that I found are part of pull request #1625:

https://github.com/apache/maven/pull/1625/commits/4bc46b4114396e6025645f3c5dae888f3d386981


Martin



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





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

Re: Terminology proposal: "Maven module" -> "Maven sub-project"

2024-08-17 Thread Matthias Bünger 

+0 I'm open to this change, but can lalso live without it, but I get the
idea and the aspects behind it.

To add to the discussion about names/phrases:

As of now we have "multi-module-project" and "single-module-project".
"(multi-)subproject-project" is as clear to me as, and "single-project"
is a as goot as "single-module-project" in my case.

Greetings

Matthias

Am 05.08.2024 um 14:14 schrieb Martin Desruisseaux:

In order to avoid confusion between "Maven module" and "Java module",
I suggest to update documentation for using "Maven sub-project"
instead of "Maven module". However, the  XML elements in the
POM would be unchanged for compatibility reason. There is apparently
not so many places in the documentation that need to be updated. The
ones that I found are part of pull request #1625:

https://github.com/apache/maven/pull/1625/commits/4bc46b4114396e6025645f3c5dae888f3d386981


   Martin




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

Re: [DISCUSS] maven-core-plugin

2024-08-17 Thread Matthias Bünger 

Hey,

as I see a lot of improvements and (ofc after the initial time effort of
the set up) time savings in the future (by not writing the same multiple
times but also to avoid introducing manual issues when you do the same
for th x times, but always a slightly different cause of the slightly
different codes,  I'm for this move forward.

Only thing I'm not sure about is the name "maven-core" for me as a fresh
guy here always relates to the maven core application but not the
plugins - I guess you mean the core basic plugins, but maybe a different
name like idk (names...) maven-general-plugin-lib or something (tried to
avoid "common").

Greetings

Matthias

P.S. Yes I've read all the discussion so far. I don't see the issue of
competing standards or "old" plugins. It's natural to deprecate and bury
old stuff in favor for new - that's somehow the core (haha) message of
Maven 4 for me. Or as I call it "Maven 4 is project jigsaw for Maven"


Am 15.08.2024 um 13:13 schrieb Tamás Cservenák:

Howdy,

as am going over multiple plugins (as it is time to upgrade parent, some
bugfix, etc), all I see is:
* a LOT of code duplication across plugins (some even have comments like in
plugin X "this should be shared with Y")
* some "forcefully" pushed out "shared" artifact to share them across
* just many too small codebases that needs a LOT of process/work effort for
small gain
* it is all chopped up into relatively small pieces

Hence, we were already discussing this idea on Slack: what if we introduce
maven-core-plugin?

One single plugin that contains some "most common" Mojos?
(nothing new under Sun, this would be the "a la Takari Lifecycle"
situation, where one plugin delivers most common Mojos -- although there
the incentive was build avoidance/incremental build).

For start, we could consider all 'core' plugins (those referenced from
maven like in lifecycle mapping) except:
* m-compiler-p
* m-surefire-p

as they are complex on their own.

WDYT?
Tamas



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

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M16

2024-07-17 Thread Matthias bünger 
+1 (nb)
Von meinem iPhone gesendet

> Am 17.07.2024 um 15:47 schrieb Michael Osipov :
> 
> Hi,
> 
> we solved 2 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12354923
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2175/
> https://repository.apache.org/content/repositories/maven-2175/org/apache/maven/plugins/maven-site-plugin/4.0.0-M16/maven-site-plugin-4.0.0-M16-source-release.zip
> 
> Source release checksum(s):
> maven-site-plugin-4.0.0-M16-source-release.zip
> sha512: 
> d49703142eea9987c621ac2c89987e9ec4c949de205ed8209caf7256bd80d7284b35b95cc07b02271510f36a60434a661a55d8239582a5d72aa64cb2b2c02f83
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

Re: [HEADS UP] Releasing maven plugins 4.0.0 beta

2024-06-20 Thread Matthias Bünger 

+1 (nb)

Am 20.06.2024 um 18:20 schrieb Guillaume Nodet:

Hey !

Following Maven 4.0.0-beta-3 release, I've been updating a bunch of plugins
to that version.
The result is the following PRs:

- [MPLUGINTESTING-94] Switch to Maven 4.0.0-beta-3
 maven-plugin-testing#39

- [MCLEAN-123] Switch to Maven 4 API and the new api
 maven-clean-plugin#20

- [MSHARED-1200] Switch to the Maven 4 API maven-filtering#46

- [MRESOURCES-308] Switch to the Maven 4 API maven-resources-plugin#35

- [MCOMPILER-593] Switch to the Maven 4 API maven-compiler-plugin#147

- [MSHARED-1415] Switch to the Maven 4 API maven-archiver#46

- [MJAR-311] Switch to the Maven 4 API maven-jar-plugin#70

- [MSOURCES-149] Switch to the Maven 4 API maven-source-plugin#19

- [MINSTALL-187] Switch to the Maven 4 API maven-install-plugin#35

- [MDEPLOY-301] Switch to the Maven 4 API maven-deploy-plugin#27



I'm thinking about creating 3.x branches for those components, merging
these PRs, and releasing them as beta-1.
Any problems with that ?

Cheers,
Guillaume Nodet



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

Re: [DISCUSS] Maven should ALWAYS install/deploy at end

2024-06-15 Thread Matthias Bünger 

+1 (nb) to make  installAtEnd and deployAtEnd properties true by default.

Am 14.06.2024 um 19:24 schrieb Jorge Solórzano:

+1 (nb) to make  installAtEnd and deployAtEnd properties true by default.

BTW, there is a note of "experimental" on the install plugin.


On Fri, Jun 14, 2024, 19:16 Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:


Le 2024-06-14 à 19 h 11, Gary Gregory a écrit :

Thank you Martin for clarifying this! If I understand correctly: If I
said 'mvn clean deploy foo bar' in a multi-module project, then 'mvn
clean foo bar' happens first for all modules followed by 'mvn deploy'
for all modules?


This is my understanding of Tamas's proposal (maybe more like "mvn
compile" for all modules followed by "mvn deploy" for all modules). But
I may be wrong, we will need his confirmation.

  Martin




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

Re: [VOTE] Release Maven Javadoc Plugin version 3.7.0

2024-05-29 Thread Matthias Bünger 

+1 (nb)

Am 29.05.2024 um 18:18 schrieb Michael Osipov:

Hi,

we solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529&version=12354465


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MJAVADOC/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2136/
https://repository.apache.org/content/repositories/maven-2136/org/apache/maven/plugins/maven-javadoc-plugin/3.7.0/maven-javadoc-plugin-3.7.0-source-release.zip


Source release checksum(s):
maven-javadoc-plugin-3.7.0-source-release.zip
sha512:
8ab35979e8c2cc9d69578b32cb61a227a4f2071c5201b97c98ece12a0a83af95f5268489e88e26dcccba0eab940bc6ac1f4d52138e8db280d0c0a61d21a379ca

Staging site:
https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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



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

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M15

2024-05-29 Thread Matthias Bünger 

+1 (nb)

Am 29.05.2024 um 17:19 schrieb Michael Osipov:

Hi,

we solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12354740


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved


Staging repo:
https://repository.apache.org/content/repositories/maven-2135/
https://repository.apache.org/content/repositories/maven-2135/org/apache/maven/plugins/maven-site-plugin/4.0.0-M15/maven-site-plugin-4.0.0-M15-source-release.zip


Source release checksum(s):
maven-site-plugin-4.0.0-M15-source-release.zip
sha512:
d0abf8630845be229e3d480eb1a74cbd0f359e96418eb7ca53a799c618d2a887ae18718bc5635587e6187ab77ed65438e1b56115dec8378eee6477d8c6cab820

Staging site:
https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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



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

Re: [DISCUSS] Removal of ineffective switch for Maven 4

2024-05-24 Thread Matthias Bünger 

For me it does and we should take the oppurtunity with Maven 4 to do so

Greetings

Matthias

Am 24.05.2024 um 13:09 schrieb Maarten Mulders:

On 24/05/2024 09:43, Michael Osipov wrote:

On 2024/05/24 07:06:45 Maarten Mulders wrote:

Hi all,

Today, I noticed Maven has an `-up` switch, for `--update-plugins`. The
help text says it's ineffective, only kept for backward compatibility.

With the advent of Maven 4, would this be a good moment to remove this
switch?


There much more of them to be killed, but before we do that we need
to make sure that any of our plugins which invoke Maven never pass
them, then we can discuss their removal.


Just checked, and indeed, there are a few more listed explicitly as
"ineffective":

-cpu, --check-plugin-updates
-npr, --no-plugin-registry
-npu, --no-plugin-updates
-up, --update-plugins

My idea would then be to see if any of these four are used in our own
code base (core as well as plugins). If there are usages, let's remove
them. That should not be hard, as they don't trigger any behaviour
anymore. After that, we can continue to drop them from the Maven CLI.

Would that make sense?


Maarten

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



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

Re: [VOTE] Release Apache Maven 3.9.7

2024-05-23 Thread Matthias bünger 
+ 1 (nb)
Von meinem iPhone gesendet

> Am 22.05.2024 um 12:10 schrieb Tamás Cservenák :
> 
> Howdy,
> 
> We solved 21 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12353964
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2125/
> 
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.7/
> 
> Source release checksums:
> apache-maven-3.9.7-src.tar.gz.sha512
> a3c211ce683afbde9c4becf8b32397d14d3e7d8e8261094da037dcf27a697a93134440e055e7a9e7e26af2db543d4d9c4e7b0296560f5193df7ba90b9a68d1d1
> 
> apache-maven-3.9.7-src.zip.sha512
> cdd8249807e251d07c613a65120058993e47a4cbf7f6dbda8599c7ca7ab4ed3fedc727e651f43cba0e9b0d604055c1106c1243be64a1d52c5ddf72dbec5e65dc
> 
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
> 
> Draft for release notes:
> https://github.com/apache/maven-site/pull/521
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72h
> 
> [ ] +1
> [ ] +0
> [ ] -1


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

Please write proper JIRA-descriptions

2024-05-18 Thread Matthias Bünger 

Hey all,

when I started to read through the Maven JIRA issues I noticed that
there are many without a description that people, who were not involved
in discussions / coding in where an issues raised from, can hardly
understand the issue and therefore also can't get their hands on or
contribute (ofc Maven is a huge and complex system where some issue are
only understandable when you know how certain things work).

Sometimes the PR gives more information, but sometimes the information
there are different from the issue.

To top this, there are sometimes issues that don't have a single
character as a description, e.g. this one from the fresh beta-2 releases
notes:

https://issues.apache.org/jira/browse/MNG-8089

Ofc an empty issue might be better than no issue to documentation the
need of something at least with a title and yes I'm a person who thinks
that proper documentation and descriptions of apps/issues/etc are
important and I like writing documentation. As this (and as a person who
tries to get deeper into Maven) I kindly ask everyone to spent some time
when creating an issue and not leave it empty or only put a short
sentences in it. I'm convinced that proper descriptions help everybody
to understand the WHAT and WHY not only for a short moment but for a
long time.

Thank you very much!

Matthias



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

Re: [VOTE] Release Apache Maven Wrapper 3.3.1

2024-04-22 Thread Matthias Bünger 

+1

Greetings

Matthias

Am 22.04.2024 um 18:28 schrieb Tamás Cservenák:

Howdy,

The importance of this release is to gain over 3.3.0: Two changes are in
this release, both are equally important, but MWRAPPER-134 adds simple
means for tooling to discover wrapper versions being used. With 3.3.0 we
lost this ability to figure out wrapper versions easily.

We solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721&version=12354586

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MWRAPPER/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2097

Source release checksum SHA512:
270d843df1b5db108f5420c3ef9310ff1238d49b077c35cff6a5eca9f584f6f41ee9d82cba169fce2c6e768281cda9d84383ec75171640163d0966cc0f206949

Staging site:
https://maven.apache.org/wrapper-archives/wrapper-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: [VOTE] Move AFS Parent POM and Maven Parent POMs issues to GitHub

2024-04-13 Thread Matthias Bünger 

Hi,

a +0 from me as I'm not that long into the Maven projekt but the first
think that came to my mind when reading this: Then why not all? And if I
remember correctly there were causes why Maven uses the (partially)
locked JIRA as an issue tracker.

Matthias

Am 13.04.2024 um 15:55 schrieb Slawomir Jaranowski:

Hi,

Rationale:

- more of changes in those projects are the dependencies updates make by
the Dependabot,  next we create issues in Jira by manual copy paste to have
a release notes
- we can use Release Drafter for preparing release notes on GitHub - no
manual works and easy to publish
- release notes on GitHub are more easier to find
- it is our internal project used in ASF

Taks to do:

- release next version ASF 32 / Maven 42 as is
- make jira project MPOM - read only
- leave current open issues in jira as is - with notes about migration - if
someone want to work on it, will copy it to GitHub
- enable issues on GitHub
- update project documentation

If the vote passes - I will take care of it.

Jira project:
https://issues.apache.org/jira/projects/MPOM

GitHub repositories:
https://github.com/apache/maven-apache-parent
https://github.com/apache/maven-parent

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: Nope, 3.5 isn't dead

2024-04-13 Thread Matthias Bünger 

Hey all,

when I gave my talk about Maven 4 some days ago at the Javaland
conference I started with a quick "what Maven version do you use"
question and there were also several hands who use 3.6 and 3.3 (!). I
hope I could convince them to upgrade - so it's the same with Java
versions: There are always people who use very old out of support version.

But as you wrote yourself: It's seems more than a "frozen" CI setup than
a Maven problem.

Matthias

Am 13.04.2024 um 13:21 schrieb Elliotte Rusty Harold:

Maybe it should be, but I wanted to drop a note that about a month
after December's decision to require Maven 3.6.3, I shifted onto an
open source project that's been around for 10+ years, is actively
backed by two large tech companies, and still depends on Maven 3.5.x
in the continuous integration build. Bleah.

I've been trying to upgrade it, but so far without success. 3.5 seems
baked pretty deeply into the Docker images or some other part of the
CI infrastructure that isn't easy to change. This project could well
be using Maven 3.5 for years to come. It's even possible we will
rewrite the whole codebase in C++ before we manage to get past Maven
3.5. (I wish that was hyperbole. It's not.)

I think we tend to overestimate how fast the installed base updates,
whether it's JDKs (I got a bug report from someone still using Java 7
yesterday), Maven versions, operating systems, or pretty much anything
else. None of us see more than a small fraction of the projects out
there. It is very easy to look at that small fraction and draw
conclusions that are falsified with a larger or different sample.

I didn't know about this dependence on Maven 3.5 until I changed
projects in January. I haven't seen 3.3 lately, but I wouldn't be
surprised if it's still in use in multiple organizations, perhaps
because it's what's installed by default in some old Linux distro that
should also be retired but isn't. Absence of evidence is not evidence
of absence, including when considering which Maven versions developers
actively use.



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

Re: maven-pmd-plugin next version? (PMD 7 Upgrade)

2024-04-06 Thread Matthias Bünger 

Hey,

I see benefit in upgrading to PMD 7, users have to adjust their rulesets
from time to time anyway. I had to upgrade the on from my team when
trying (and failing ^^) to upgrade vom maven-pmd-plugin sub 2.14 to 2.21
too due changed/deprecated rules.

>The question is now: Should the next version of m-pmd-p be called
3.22.0 or 4.0.0?

There was a discussion the list that maven plugins should start with a 4
when they are upgraded to the Maven 4 plugin API (I hope the wording is
correctly). So if this is not the case (and "only" the PMD version") is
listed I would argue to not call it 4.0.0 but 3.3.1 (to show the bump of
PMD via minor version).

Greetings

Matthias

Am 05.04.2024 um 21:42 schrieb Andreas Dangel:

Hi all,

I'd like to hear your opinions about [1] / [2]:

Adding support for PMD 7, which is a major version upgrade from PMD
6.55.0, might impact end-users under certain conditions: If they use
custom rulesets and use a rule, which no longer exists or has been
replaced, they need to update their rulesets so that it will be
working with PMD 7. Or if they have written custom rules.

Using PMD 7 however, enables support for Java 21. Upgrading PMD in
m-pm-p would bring this to all users. While m-pmd-p itself didn't
change much (e.g. the maven configs are still valid), the underlying
PMD of course did (and therefore any custom rulesets might need to be
updated).

This fact, that there might be changes needed when upgrading, will be
added on the plugin documentation page [3] under "Upgrading notes"
(part of PR 144).

The question is now: Should the next version of m-pmd-p be called
3.22.0 or 4.0.0?

If there are no objections, I would merge PR 144 and start a release
of m-pmd-p as 3.22.0 some time next week.


Thanks,

Andreas


[1]: https://github.com/apache/maven-pmd-plugin/pull/144
[2]: https://issues.apache.org/jira/browse/MPMD-379
[3]: https://maven.apache.org/plugins/maven-pmd-plugin/index.html




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



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

Re: [DISCUSS] Maven Core Plugins versioning

2024-03-08 Thread Matthias Bünger 

+1

Am 08.03.2024 um 13:00 schrieb Tamás Cservenák:

So, can we agree on following (maybe even vote if needed)?

I. Core Plugin Versioning
Maven3 plugins carry 3.x as the major version number, and Maven4 plugins
will carry 4.x major versions?

II. Consequence: How to interpret Core plugin versions
See above. In short: the first element is "maven API level", rest could be
"shifted left" and interpreted like that.

III. Consequence: How to express Core plugin "breaking change"?
Ideally, we should NOT have them. But, in case we must:
- use minor bump and .0 patch to clearly show this is a "bigger" change
(hence, 3.1.0 -> 3.2.0 should be interpreted by users like "I need to sift
thru release notes before just blindly update")
- clearly document the breakage in plugin release notes, plugin announce
and plugin site

(new) IV. Doxia should be handled similar to Resolver
- Doxia 1.x is Maven 3 (as today, m-site-p 3.x is Maven3 plugin and uses
Doxia 1.x stack)
- Doxia 2.x is Maven 4 (in future, m-site-p 4.x will be Maven4 plugin and
will use Doxia 2.x stack)
As this then solves all the problems Michael brought up rightfully.

T



On Fri, Mar 8, 2024 at 12:27 PM Tamás Cservenák  wrote:


And a short addendum:

Given, today there are still no Maven 4.x plugins nor Doxia 2.x reports
out there (released), what if, we follow Michael intent BUT with a slight
"bend":
- the new Maven Site plugin that uses Doxia 2.0.0 and would carry version
4.0.0 (to be released) **should be Maven4 plugin**
- this implies that all reports stuff that will Doxia 2.0.0 MUST BE Maven4
plugins as well
- basically, leave Doxia 1.x for Maven3 as is, and use Doxia 2.x for Maven4

T

On Fri, Mar 8, 2024 at 12:20 PM Tamás Cservenák 
wrote:


Just to clarify, explain myself but also FTR on thread:

in case of report-plugins we basically have TWO requirements (or deps):
- maven API level
- doxia API level (that with 2.0.0 contains breaking changes)

Basically, Maven4 supports 4.x plugins (that use new API) but also
supports running 3,x plugins (in "compat" mode, just like today, as there
are still no 4.x plugins out there).
But Doxia introduces hard breakage, as far as I understand (correct me
here if I am wrong), there is no "Doxia 2.x backward compat support for
Doxia 1.x clients"?

Given Doxia 1.x is being phased out, and unlike for Maven API (where we
do want and will maintain 3.x and 4.x plugin versions in parallel), this is
not happening with reports/doxia.
We do not want any Doxia 1.x report to be released, right?

This also implies that a build that does use reports, cannot "gradually"
migrate to Doxia 2.0.0, no?
It is all or nothing, no? So either a new site plugin with Doxia 2.x or
an old site plugin with Doxia 1.x?

T

On Fri, Mar 8, 2024 at 11:50 AM Tamás Cservenák 
wrote:


Howdy,

First, 4.0 is not out yet (check my remark in the initial mail "M
releases do not count").

Second, is there a plugin out there that also includes a report?
(or in other words, you remember I was insisting to SPLIT OUT all the
report stuff out of plugins)

As if there is no such plugin, we deal with them just like explained
above in case of "breaking changes":
basically report-plugins will have breaking changes and will require new
site stuff...

If there is a plugin that includes report as well, report MUST be
split out as the first step.

T

On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov 
wrote:


Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:

So, can we agree on following (maybe even vote if needed)?

I. Core Plugin Versioning
Maven3 plugins carry 3.x as the major version number, and Maven4

plugins

will carry 4.x major versions?

See Maven Site Plugin 4.0, contains fundemantal changes in the
background, cannot keep 3.x. Same will apply to almost all of our
reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
Maven 4. How do deal with that?

M


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



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

Re: [DISCUSS] Maven Core Plugins versioning

2024-03-06 Thread Matthias bünger 
Hey all,
my thoughts on these questions are quite that we should keep it as simple as it 
is:

I see value in keeping the versioning and its semantics with the Maven API at 
the first slot. This makes it an easy to see indicator and keeps the experience 
/knowledge of long time Maven users. About the question for breaking changes: 
The minor version (2nd slot) can be the indicator for major changes (breaking 
or not) - don‘t forget the documentation aside the version number. We can 
easily describe the version semantic in general and list/highlight (breaking) 
changes in the release notes or maybe add an addional indicator (eg a 
„breaking“ flag in the versions overview). Also remember yourself: With Maven 
3.9.0 the required Java version to run Maven was lifted to 8 - so breaking 
change without increasing the first number - indicated by another color (and 
the different number) in the java coloumn on the release page. 
At my work we do similar versioning semantic like the Maven one: our XSD where 
the first number is equal to version of the system of our major internal 
service provider (who handles in- and outcoming files). 

Greetings
Matthias







Von meinem iPhone gesendet

> Am 06.03.2024 um 14:59 schrieb Tamás Cservenák :
> 
> Howdy,
> 
> We have several topics that need to be discussed.
> 
> I. Core Plugin Versioning
> 
> History: When Maven2 was born, and started using plugins "as we know them
> today" (Maven 1 was a very different beast), the Core Plugin versions were
> started as 2.0 on purpose. Just check the Maven Central for historical
> versions, some examples:
> * clean
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> * compiler
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> * jar
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> * surefire
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> * dependency
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
> 
> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> beginning. Later on, when Maven3 came to existence, it was able to use
> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
> major plugin version jump.
> 
> So far, we have no 4.x plugin release of anything (M releases do not
> count). But my question is the following:
> 
> How should we distinguish similar changes for Maven4?
> 
> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> will NOT be able to use anymore (will be incompatible). Similarly as
> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> capability for some time. But other ways it does not work, nor never worked
> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> Maven3 plugin).
> 
> For me, the logical answer to this question is the use of major version
> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> plugin" (Maven2 incompatible).
> 
> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> confuse the hell out of our users. At least that is what I think.
> 
> II. Consequence: How to interpret Core plugin versions
> 
> As can be seen above, so far the major version of the plugin was kinda
> showing "which Maven API level" is the plugin.
> 
> So, it begs the question: HOW to interpret the Maven Core Plugin version?
> 
> My interpretation was always: "shift it once left", meaning: Core plugin
> version "3.2.1" MEANS:
> - Maven API version: 3
> - Core Plugin version 2.1(.0)
> 
> III. Consequence: How to express Core plugin "breaking change"?
> 
> Today, everyone expects a "major version jump" to express breaking changes.
> BUT, as explained above, that would be totally misleading here, and would
> break the "customary law" that Major expresses Maven lineage.
> 
> Ideas and opinions welcome.
> 
> T


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

Why is hardcoded groupId needed for automatic module/parent resolving in Maven 4?

2024-03-03 Thread Matthias Bünger 

Hey all,
I was double checking my Maven 4 examples and was wondering why
automatic version resolving of module dependencies only works when the
groupId is set fixed, but not working when using the project's variable.

To make my question clearer - let's assume a multi-module project with
groupId "test.bukama.maven" and two modules ("ModuleA" and "ModuleB")
where one has the other as a dependency (It's the same with parent
versioning, not only module dependencies btw):

In Maven 3.9.x you can define a module dependencies using projects
variables for "groupId" and "version", e.g.

  
  
    ${project.groupId}
    ModuleA
    ${project.version}
    
  

With automatic versioning in Maven 4 you can write

  
  
    test.bukama.maven
    ModuleA
    
  

and get rid fo the repeatabled versions. But when you use the project's
variable for the groupId like in Maven 3.9.x

  
  
    ${project.groupId}
    ModuleA
    
  

you get an error that the version definition is missing:

[ERROR]   The project test.bukama.maven:ModuleB:0.0.1-SNAPSHOT
(D:\Github\Maven4\Maven4\ModuleB\pom.xml) has 1 error
[ERROR] 'dependencies.dependency.version' for
test.bukama.maven:ModuleA:jar is missing. @
test.bukama.maven:ModuleB:[unknown-version],
D:\Github\Maven4\Maven4\ModuleB\pom.xml, line 11, column 9

The "root" attribute is set to "true" in parent-pom and not set in the
module-poms!

As I havn't found anything on the JIRA about this (but maybe overseen
it), may I ask why you have to hardcode the groupId for automatic
versioning to work? Why Maven 4 assumes the parents project version for
the missing version but does not do the same for the groupId?

Thank you!
Matthias

P.S. For me personal the best would be to only write the artifact of the
projects own module (I think was working in alpha1-snapshot back then if
I remember correctly), but getting rid of the version is most important
for me :)


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

Re: Use of jspecify in Maven

2024-02-12 Thread Matthias Bünger 

(I'm neither a Maven core or plugin maintainer)

I don't like such annotations as in my opinion, they save you nothing,
but bring an addional dependency and problems with the tools that
(don't) support (only a specific version of) them.

If my method needs arguments that are not null than I have to check them
and throw an exception if the caller of the method tries to pass NULL
into it. If I'm too lazy to check my parameters than I deserve it to get
NPE e.g. (funny enough an external coder with 20+ years of experience at
my work just experience that exactly now, as he just relies that
everything is always there...).

Am 11.02.2024 um 22:27 schrieb Benjamin Marwell:

Hello devs and plugin maintainers!

Since JSR 305 (Nullable annotations etc.) did not get implemented
officially, and Maven allows `null` in a lot of locations, I wanted to
ask about your opinions about using jspecify: https://jspecify.dev/

JSpecify was created by the Java community (i.e. Java decs but also
larger corporations like Google, if I am not mistaken. It was seen as
needed since JSR 305 never materialized and probably never will.
Google hat a Guava Situation [1] and decided to do something about it.

JSpecify says it is safe to adopt it [2]. Although the current version
is 0.3, it is more like 0.9.

I honestly think that Maven would benefit from those annotations, as
many recent libraries try to avoid `null` as best as they can. Younger
developers may not be used to seeing nullable parameters, and even
some of us don't know which parameters can be nulled (or not).

Let me know what you think about this idea.

My personal opinion: I am pretty confident jspecify will displace
checker-qual as the "top dog" of nullness annotations in the future. I
also want to give plugin authors a way to use null in their plugins,
too, although we could make it an optional dependency (just
annotations...).

Looking forward to reading your opinions!

- Ben

1: https://github.com/google/guava/issues/2960
2: https://github.com/jspecify/jspecify/wiki/adoption

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



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

My first expierence trying to contribute code

2024-02-03 Thread Matthias Bünger 

Hey all,
in this mail I want to share my experiences / thouhgts I had on my way
from the decision to contribute some code to the Maven project, because
I think there are some things which may be improved. But before creating
issues about that I wanted to write here, as it's heavly opinion based
(obviously ;) ).

To my background: At my work I don't code that much as some years ago,
but do a lot of team lead, mentoring and (not only as part of the first
two things) documentation (funny enough one of the documentation I
currectly overhaul is the one for onboarind new team members and get
them to work). I'm also one of the maintainers of the JUnit extension
library "Pioneer" where I primely care about issues and documentation.
---

IDE setup and code style:

When I decided trying to contribute some small code fragements as a
first step I first tried to setup my IDE. So I checked the coding rules
on the Code style page
(https://maven.apache.org/developers/conventions/code.html)


As I'm more used to Eclipse and it's workspace concept I tried to set up
this first. Imported the "import order"-file and all except coding
style. I read the instructions to compile the palantir Java plugin
(never heart about palantir before) which worked (I think, needed to
switch to an older JDK for it) but I noticed nothing in Eclipse of it.
So I tried IntelliJ as I read on the plugin page that it is available in
the plugin store there. As not that familiar it took quite a long time
for me to set up a project (workspace) with multiple maven modules, but
finally I got it. And also got the palantir plugin to worked.

To finish the story of coding style: After I coded somthing the build
failed as the Spotless plugin said my code does not match the style.
That confused me quite a lot as that should be done by the planatir
plugin. But in some places it did not what the spotless check wanted to
have. I then decided so give a  about palantir and only use
spotless. I think a statement on the website that the spotless plugin is
configured and can/should be used would make it easier I think


Mojo docs:
After I've set up my IDE I wanted to know how plugins work so I took the
Mojo docs and tried to understand by using a quite simple plugin (clean
plugin)


When I read the "Common Bugs and Pitfalls" page
(https://maven.apache.org/plugin-developers/common-bugs.html) I was very
confused by the code examples. First I wondered why they are all labeld
with fixme and therefore not up to date? I then realized that all code
examples are the "don't do it that way" examples, but the "how you do it
right" is only written in text (or not at all, e.g. the Logging example)
- without any code examples. From my experience with juniors at my work
and from how (many) people in the internet people mostly only look at
the code examples without further reading the sentences around the examples.

I think Benjamin agrees me about that, do you? ;)
(https://x.com/bmarwell/status/1751539018389475558?s=20)

Logging:
Information about loggin are wide spreaded and I think that's not good.

- At "Maven 3.1.x loggin" what framework Maven uses, but there is not
shown how to get the correct logger or logging example
- At the pitfalls page only the bad one is shown, but not the correct one
- At the "Maven loggin" page it shows that you should you use
"Logger.getLogger" but in mosts Mojo codes of plugins (let's take a
SNAPSHOT of the maven site plugin) always "getLog()" is used and it took
me some time to understand the difference to the pitfalls page bad example

I suggest to bring that in line and connect it more or centralize it.


Integration tests:
I find it hard to find a good documentation about how to write and
execute integration tests. On the "testing a plugin" page there is a
link to a wiki article from 2018. Doesn't make me feel compfortable.


Other:
- There's a "TODO creating and using custom packaging" at the plugin
developer centre start page.
- There's a formatting error on the pitfalls page
- I opend my first PR about three weeks ago and didn't get any response
yet. I know all do this in their spare time and I wouldn't expect
responses when opening issues (and I didn't get one since months on my
first JIRA issue), but from my expierence it's always good  to show at
least some reaction (esp. to new contributes) - even if it's only to
thank him and to tell him that a review may be delayed.

I know I'm not yet deep into Maven, but I wanted to share my thoughts of
my first steps.

Have a good weekend
Matthias


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

Re: Java version for Maven 4?

2024-01-22 Thread Matthias Bünger 

I'm close to Ben and Manfred,

I think Maven can get a lot of value (for maintaining as for runtime) by
switching to Maven 21 a base for itself.

Matthias

Am 22.01.2024 um 13:33 schrieb Benjamin Marwell:

To add some more information, I have seen some extreme reduction in
build times after switching from Java 11 to 17 or even 21 (just for
build, not the runtime).
We can still verify it runs on 11/17 by using the integration tests,
but having the (possibly parallel) unit- and integration tests
compile, run and package on 21 is an *extreme* improvement in build
time.

As always, YMMV. But why waste time...

Since with Semeru and Temurin all major vendors have published their
JDK21 at last,
I see no reason to use a lower Java version to build maven with.
It is easily available for everyone who wants to contribute.

If I read the thread correctly, there were no objections to raising
the build time requirements.

It will also remove a lot of unneeded profiles (Java 8 Javadoc fix,
possibly build chains and module-info profiles),
in case any of those are present.

- Ben

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



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

Re: [VOTE] Release Apache Maven 4.0.0-alpha-12

2024-01-12 Thread Matthias bünger 
+1

(And +1 to try not to burn versions. I was also confused that I „missed“ 11. 
Thanks for explanation why it was skipped)

Von meinem iPhone gesendet

> Am 12.01.2024 um 11:44 schrieb Guillaume Nodet :
> 
> I'm starting a new vote to release this new alpha.
> This release brings the latest Maven Resolver 2.0.0-alpha-6, leveraging
> artifact collection filtering and the new transitive dependency manager.
> JLine has been leveraged to provide better line editing, SLF4j has been
> upgraded to 2.x. Also, projects are not resolved anymore outside the
> reactor to provide better consistency during builds.
> 
> Fwiw, a few plugins have already been ported to the new API (clean,
> install, deploy, resources, compiler) and do pass their integration
> tests, i'll update the PR
> https://github.com/apache/maven/pull/1048
>  asap.
> 
> 13 issues solved:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12354059
> 
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2062
> 
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-12/
> 
> Staged site:
> https://maven.apache.org/ref/4-LATEST/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72h
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> --
> 
> Guillaume Nodet


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

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

2024-01-09 Thread Matthias Bünger 

Hey all,

I'm a new user of the list so I don't know later discussions.

I would lift the minimal API version to the newest available one:

Two reasons for this:

- You / we want to cut some old tails with Maven 4. This should also be
a good time to cut old tails for maven plugins, esp. as there were
several APIs changed / removed (I have read this multiple times, but I
don't know the details as I have never coded a Maven-plugin yet)

- Users who want to stick to older versions can still use Maven 3 (I'm
totally with Karl-Heinz here). But even here I would upgrade to newest
possible.

Further background / information about me / my point of view: I'm one of
the maintainer of the JUnit Pioneer extension library and have similar
concerns there: What JUnit Jupiter version do we required? In our case
we have decided to keep the lowest we need for our extensions - even
when they are sometimes somehow experimental. But the huge difference
beweetn the Pioneer/JUnit connection and the one discussed here is: The
maven team owns both and can therefore decide far more independent (and
with a the current "drop old tails" situation can/should be a bit more
"egoistic" in my point of view.

Have a good evening

Matthias


Am 29.12.2023 um 18:39 schrieb Michael Osipov:

Am 2023-12-29 um 14:42 schrieb Slawomir Jaranowski:

Hi,

Last year we mark all Maven versions 3.6.x and older as EOL [1]

But we still try to support minimal API version for Core Maven
Plugins as
3.2.5

I would like to  propose to sich it for at least to 3.6.3

Reasonable reasons: (for me)
  - for standard CI build we use Maven 3.6.3 and newer
  - many of external plugins, like MojoHaus are switched to 3.6.3
  - we have a hacks in code to try support old version in plugin, like
in: EnhancedPluginDescriptorBuilder in plugin-tools [2], we can cleanup
such code
- I don't believe to someone want to do more fixes for EOL Maven
version in
plugins - so we should be a honest for users
- and we should go forward

[1] https://maven.apache.org/docs/history.html
[2]
https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-report-plugin/src/main/java/org/apache/maven/plugins/plugin/descriptor/EnhancedPluginDescriptorBuilder.java




I remember that we had a discussion that the next base/API version
should be 3.5.4 because it is the first version using
org.apache.maven.resolver:maven-resolver-api [1]. Please don't confuse
API compat with maintenance/support for a specific Maven version. I
believe that we have made this clear more than once.

Is thre anything specific fixed in 3.6.3 behavior you consider crucial
which makes maintenance easier than with 3.5.4?

M

[1]
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup

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



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