Re: [VOTE] Release Apache Maven 4.0.0-rc-3

2025-03-06 Thread Romain Manni-Bucau
+1

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le jeu. 6 mars 2025 à 22:02, Matthias Bünger  a
écrit :

> +1 (nb)
>
> Am 05.03.2025 um 12:15 schrieb Guillaume Nodet:
> > We solved 108 issues since rc-2.
> >https://issues.apache.org/jira/projects/MNG/versions/12355493
> >
> > Staging repositories:
> >https://repository.apache.org/content/repositories/maven-2278/
> >https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-rc-3/
> >
> > Source release checksums:
> >apache-maven-4.0.0-rc-3-src.tar.gz.sha512
> >
> >
> 45bd4395afb6630236cbdd2e0da8441e73da5b93cdfcb4497565b93130ca2595348a703863635f7e160afa0ad05e4e508d39157e63f49d9868ed6a8e984fa26e
> >
> >
> >apache-maven-4.0.0-rc-3-src.zip.sha512
> >
> >
> 3c9a2abf67d472aabe30fb9a8a3b95409f1e6314f6b2f19325a9072d95e5fed0720d95440f6219f06a95df403c72b902aa5140b09442535a91eae7eb11e6bfd3
> >
> >
> > Staged site:
> >https://maven.apache.org/ref/4-LATEST/
> >
> > Draft for release notes:
> >https://github.com/apache/maven-site/pull/714
> >
> https://github.com/apache/maven/releases/tag/untagged-bf6d7ced53b3f15062ce
> >https://gist.github.com/gnodet/3a0b495ec4f6eba81559a228ceabdc7e
> >
> > Guide to testing staged releases:
> >
> http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > The vote is opened for at least 72h:
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


Re: [DISCUSS] Support YAML poms

2025-03-06 Thread Christoph Läubrich

but it would also mean IDE which will stay the main blocker
for adoption


m2e already support polyglot extension because it uses mavens 
model-reader to read the "real" pom so there is no need for an IDE to 
adopt to every format.


Beside that, as polyglot is already there [1], why not put it in there 
(maybe in a 4.x branch for maven 4 only).


Then everyone who likes can simply enable the extension for their build 
and it would be good to have it maven4 compatible anyways.


[1] https://github.com/takari/polyglot-maven/tree/master/polyglot-yaml


Am 05.03.25 um 21:26 schrieb Romain Manni-Bucau:

Guess the main question is what do we do of all extensions, we can maybe
create a maven-extension-proposal repo and put all the draft and tests
there and promote them to top level repo if users adopt it (but it would
also mean IDE which will stay the main blocker for adoption IMHO).

In terms of format itself I guess we should refine the XML (attribute etc)
first but json or json5 can be interesting things to evaluate. Hocon and
yaml have their ecosystem but are far to be interoperable and generally
readable so it sounds like something we can't integrate ore than an
extension outside the core of the project in terms of maintenance.

Just my 2 cts.

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le mer. 5 mars 2025 à 21:17, Elliotte Rusty Harold  a
écrit :


Please no. YAML is a utter mess full of sharp edges to hurt the
unwary. It's poorly understood, poorly specified, and poorly
documented. It's not clear there are any confomrant parsers or indeed
that the concept of conformance  even makes sense for something so ill
specified. If you must have something that's not XML, then JSON is the
far superior choice, but even that would be a mistake, just not as
disastrous a one. I really don't want to see multiple formats out in
the wild. One is the right number. Anything more than that increases
complexity for no particular value. That's complexity for both users
who need to understand two formats and tools that need to support two
formats.

On Wed, Mar 5, 2025 at 4:17 PM Guillaume Nodet  wrote:


Hey !

A while ago, I created a Hocon based POM parser [1], leveraging Maven
4 new capabilities to support new syntaxes for POMs.
However, as much as that syntax seems interesting, I've been pointed
that it's not really supported. So I never actually released it.
But I'd still like to get out a new syntax and so I wrote one to
support the well known YAML syntax.  I thus created a small extension
to support it [2].
It's much more concise wrt GAV ids and especially dependencies [3].

So I'd like to get it into the Maven project and release it.

[1] https://github.com/apache/maven-hocon-extension
[2] https://github.com/gnodet/maven-yaml-extension
[3]

https://github.com/gnodet/maven-yaml-extension/blob/master/src/test/resources/dependency-gav.yaml#L21-L30


--

Guillaume Nodet

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




--
Elliotte Rusty Harold
elh...@ibiblio.org

-
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] Support YAML poms

2025-03-06 Thread Maarten Mulders

Hi,

-1 from me.

It has nothing to do with all the things you can dislike about YAML. 
It's a matter of what we spend our time on.


I don't think we should invest too much effort in having additional 
formats for the POM in Maven itself. We now have one format (XML) for 
the POM. This, together with all the other ideas on our backlog, already 
provides us with more than enough work.


For those who do like YAML, it's great that they can write their POM in 
that format. But such additions do not belong into Maven itself. They 
could be separate projects, maintained by those who care. The Maven team 
should not maintain them.



Thanks,


Maarten

On 05/03/2025 17:16, Guillaume Nodet wrote:

Hey !

A while ago, I created a Hocon based POM parser [1], leveraging Maven
4 new capabilities to support new syntaxes for POMs.
However, as much as that syntax seems interesting, I've been pointed
that it's not really supported. So I never actually released it.
But I'd still like to get out a new syntax and so I wrote one to
support the well known YAML syntax.  I thus created a small extension
to support it [2].
It's much more concise wrt GAV ids and especially dependencies [3].

So I'd like to get it into the Maven project and release it.

[1] https://github.com/apache/maven-hocon-extension
[2] https://github.com/gnodet/maven-yaml-extension
[3] 
https://github.com/gnodet/maven-yaml-extension/blob/master/src/test/resources/dependency-gav.yaml#L21-L30




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



Re: [VOTE] Release Apache Maven PDF Plugin version 1.6.2

2025-03-06 Thread Matthias Bünger

Hi Elliotte,

the PR (Feb 28) was not opend when I merged (Feb 27) everything and
updated my local repo to slowly do the release. Until the vote it took
some time, because it's my first time doing this and needed to take
several basic taks, like keys etc. I didn't noticed that dependabot
opened a new PR.

Because of the very little usage of the minI think there's no notable
benefit in canceling the release and start a new one. So I would like to
continue (see this as +1nb to the vote) and close the dependabot PR.

Matthias


Am 04.03.2025 um 23:52 schrieb Elliotte Rusty Harold:

as long as we're releasing this none more time, should
https://github.com/apache/maven-pdf-plugin/pull/67 be merged first?

On Tue, Mar 4, 2025 at 6:25 PM Matthias Bünger
 wrote:

Hi,

We solved 3 issues:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317620&version=12355704&styleName=Text

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

Changes since the last release:
https://github.com/apache/maven-pdf-plugin/compare/maven-pdf-plugin-1.6.1...maven-pdf-plugin-1.6.2

Staging repo:
https://repository.apache.org/content/repositories/maven-2277
https://repository.apache.org/content/repositories/maven-2277/org/apache/maven/plugins/maven-pdf-plugin/1.6.2/maven-pdf-plugin-1.6.2-source-release.zip

Source release checksum(s):
maven-pdf-plugin-1.6.2-source-release.zip sha512:
c5890b8aa9cf2990cf03fc65eea7736b68d990d5d78206cbc8f364078469b4eb4f339882f75bff380231259a920e930b1d53a011ebbc9b8302ae5fa4c4ddaae4

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

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

Vote open for at least 72 hours.
-

Matthias


-
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-rc-3

2025-03-06 Thread Matthias Bünger

+1 (nb)

Am 05.03.2025 um 12:15 schrieb Guillaume Nodet:

We solved 108 issues since rc-2.
   https://issues.apache.org/jira/projects/MNG/versions/12355493

Staging repositories:
   https://repository.apache.org/content/repositories/maven-2278/
   https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-rc-3/

Source release checksums:
   apache-maven-4.0.0-rc-3-src.tar.gz.sha512

45bd4395afb6630236cbdd2e0da8441e73da5b93cdfcb4497565b93130ca2595348a703863635f7e160afa0ad05e4e508d39157e63f49d9868ed6a8e984fa26e


   apache-maven-4.0.0-rc-3-src.zip.sha512

3c9a2abf67d472aabe30fb9a8a3b95409f1e6314f6b2f19325a9072d95e5fed0720d95440f6219f06a95df403c72b902aa5140b09442535a91eae7eb11e6bfd3


Staged site:
   https://maven.apache.org/ref/4-LATEST/

Draft for release notes:
   https://github.com/apache/maven-site/pull/714
   https://github.com/apache/maven/releases/tag/untagged-bf6d7ced53b3f15062ce
   https://gist.github.com/gnodet/3a0b495ec4f6eba81559a228ceabdc7e

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

The vote is opened for at least 72h:

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



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



Re: [DISCUSS] Support YAML poms

2025-03-06 Thread Hervé Boutemy
I see the interest of improving maintainability of build POM beyond what has 
already been 
achieved with inference (did I say I loved your presentation [4] and this term?)
But as already expressed, I fear the risk of confusion and time taken...


Your approach of not just discussing but providing concrete examples based on 
implementation makes me hope we can get some good learning from this 
re-launched 
discussion


This time, I promise myself I'll write a summary of useful feedback from 
everybody: I'll 
probably put in the Wiki, even if I know that such notes may not be easy to read


on XML vs JSON vs YAML vs ... I won't dig much for now: later


I'd like to point to a few concrete very original topics I saw in your examples:


- id vs groupId + artifactId + version + ..., and even id + other field = 
"overlapping fields"?: 
this could probably be applied in XML (base format independent in fact)


- in dependencies coordinates, to classical g:a:v:t:c, you added the dependency 
scope field 
(eg. provided): ouch! not convinced it is a good idea. But having dependencies 
sorted by 
scope first could be interesting. Or use a different separator than : would 
improve 
visibility, like g:a:v@scope, or scope|g:a:v (again base format independent)


These 2 aspects are interesting, IMHO, even in XML (that could be a faster 
first step)


In addition, I'd be interested in feedback on these 2 topics from people doing 
tools that 
update pom.xml file:
- maven plugins, like m-release-p or m-version-p (or ... please name others you 
know)
- IDEs


I hope we'll manage to keep a concise useful discussion, and make some progress 
on 
pom.xml maintenance


Regards,


Hervé


[4] https://gnodet.github.io/maven4-presentation/[1]


Le mercredi 5 mars 2025, 17:16:17 CET Guillaume Nodet a écrit :
> Hey !
> 
> A while ago, I created a Hocon based POM parser [1], leveraging Maven
> 4 new capabilities to support new syntaxes for POMs.
> However, as much as that syntax seems interesting, I've been pointed
> that it's not really supported. So I never actually released it.
> But I'd still like to get out a new syntax and so I wrote one to
> support the well known YAML syntax.  I thus created a small extension
> to support it [2].
> It's much more concise wrt GAV ids and especially dependencies [3].
> 
> So I'd like to get it into the Maven project and release it.
> 
> [1] https://github.com/apache/maven-hocon-extension
> [2] https://github.com/gnodet/maven-yaml-extension
> [3]
> https://github.com/gnodet/maven-yaml-extension/blob/master/src/test/resourc
> es/dependency-gav.yaml#L21-L30




[1] https://gnodet.github.io/maven4-presentation/


Re: [DISCUSS] Support YAML poms

2025-03-06 Thread Guillaume Nodet
I'm well aware of the Takari Polyglot project.  However I don't want to
spend time to rewrite it all to Maven 4.  The Maven 4 architecture allows a
much better support for additional syntaxes by leveraging a new clear SPI
and the fact that we have the consumer POM and build POM.  The build POM is
the original (non xml) POM, but the consumer POM is automatically
translated to XML.
Polyglot focuses more on using programming languages to read the POM, for
example groovy, clojure, ruby, scala.  Xml and Yaml are the only two
"static" mappings.  While some may find the dynamic one interesting, I
think the static ones are more useful, because they can more easily be
translated back from the model object to the syntax.  Which is very useful
if you want to have tooling that can modify the pom.

FWIW, the implementation of the hocon and yaml extensions for Maven 4 only
consists in 2 classes: the first one is the actual ModelParser
implementation which reads the file and the delegate to the
MapModelReader.  This class translates a recursive Map into
a Model object.  The nice thing is that this class is completely generated
from the Modello model, and can be reused across all kind of "static"
mappings: JSON, YAML, HOCON, TOML, etc...  Once a parser can parse the file
into an Map, we're done.  So I want to limit my experimentation to things
that can be generated.  Fwiw, I found a library which supports the 4
syntaxes above with a single api...

Anyway, one of the big drawbacks for these is that I don't think there is
any parser which could be easily extended to track locations the way we do
with XML.   Or maybe Jackson for JSON (it can support a few fancy syntax
tricks, but not many and values must be quoted, which I find a bit
verbose...)

I may come back with an experiment for the XML.  It should be fairly simple
to hack the existing template which generates the MavenStaxReader to
support attributes for elements which have a simple type, and support
  
instead of
  
For properties or plugin config, the usual java properties syntax could be
used
   
  java.release = 17
  maven-compiler.version = 3.11.0
   
  Or for plugin configuration:
   
  skip = false
  release = 17
   

Anyway, if any one is interested, there's definitely room for experiments.
Previously it would have required the creation of a modello generator, but
now a single file (velocity template) is needed, so feel free to give it a
try !

Le jeu. 6 mars 2025 à 19:12, Hervé Boutemy  a écrit :
>
> I see the interest of improving maintainability of build POM beyond what
has already been
> achieved with inference (did I say I loved your presentation [4] and this
term?)
> But as already expressed, I fear the risk of confusion and time taken...
>
>
> Your approach of not just discussing but providing concrete examples
based on
> implementation makes me hope we can get some good learning from this
re-launched
> discussion
>
>
> This time, I promise myself I'll write a summary of useful feedback from
everybody: I'll
> probably put in the Wiki, even if I know that such notes may not be easy
to read
>
>
> on XML vs JSON vs YAML vs ... I won't dig much for now: later
>
>
> I'd like to point to a few concrete very original topics I saw in your
examples:
>
>
> - id vs groupId + artifactId + version + ..., and even id + other field =
"overlapping fields"?:
> this could probably be applied in XML (base format independent in fact)
>
>
> - in dependencies coordinates, to classical g:a:v:t:c, you added the
dependency scope field
> (eg. provided): ouch! not convinced it is a good idea. But having
dependencies sorted by
> scope first could be interesting. Or use a different separator than :
would improve
> visibility, like g:a:v@scope, or scope|g:a:v (again base format
independent)
>
>
> These 2 aspects are interesting, IMHO, even in XML (that could be a
faster first step)
>
>
> In addition, I'd be interested in feedback on these 2 topics from people
doing tools that
> update pom.xml file:
> - maven plugins, like m-release-p or m-version-p (or ... please name
others you know)
> - IDEs
>
>
> I hope we'll manage to keep a concise useful discussion, and make some
progress on
> pom.xml maintenance
>
>
> Regards,
>
>
> Hervé
>
>
> [4] https://gnodet.github.io/maven4-presentation/[1]
>
>
> Le mercredi 5 mars 2025, 17:16:17 CET Guillaume Nodet a écrit :
> > Hey !
> >
> > A while ago, I created a Hocon based POM parser [1], leveraging Maven
> > 4 new capabilities to support new syntaxes for POMs.
> > However, as much as that syntax seems interesting, I've been pointed
> > that it's not really supported. So I never actually released it.
> > But I'd still like to get out a new syntax and so I wrote one to
> > support the well known YAML syntax.  I thus created a small extension
> > to support it [2].
> > It's much more concise wrt GAV ids and especially dependencies [3].
> >
> > So I'd like to get it into the Maven project and release it.
> >
> > [1] https://github.co