Re: Parallelising custom plugin (rust-maven-plugin)

[Romain Manni-Bucau]

Le ven. 20 oct. 2023 à 21:48, Adam Cimarosti  a écrit :

> I don't think I can really split things into a different modile as the
> plugin writes binaries to the /target/classes directory for inclusion in
> the jar file.
>

This is not a blocker if you aggregate in a 3rd module.



> Could you go into more details on what would be involved in a custom life
> cycle?
>

An extension rewriter the pom to.add skip flag to compiler plugin when
yours is enabled then in yours you do what you want.

For ex https://github.com/sormuras/junit-platform-maven-plugin replaces
surefire.


> Would you have some pointers for this (class names, docs, examples)? It
> exceeds my Maven-fu ;-).
>
> Thanks,
> Adam
>
>
> On Fri, 20 Oct 2023, 20:32 Romain Manni-Bucau, 
> wrote:
>
> > Hi,
> >
> > did you try splitting rust and java code in 2 modules and using
> > -T$something ? would do it, otherwise you probably need to write an
> > extension which will capture compiler config, make it skipped to replace
> it
> > but a custom lifecycle management in your own plugin but looks more
> > complicated to achieve this goal.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 20 oct. 2023 à 21:28, Adam Cimarosti  a
> > écrit :
> >
> > > Hello,
> > >
> > > I am the author of the rust-maven-plugin (
> > > https://github.com/questdb/rust-maven-plugin/).
> > >
> > > We use this plugin ourselves at QuestDB and in CI `mvn compile` takes
> > > around 8 minutes.
> > >
> > > It appears that the Java and Rust builds happen serially.
> > >
> > > Is there a way to parallelise things so our plugin kicks off building
> > Rust
> > > in parallel while the Kava code is building?
> > >
> > > Your advice is much appreciated!
> > >
> > > Thanks,
> > > Adam
> > >
> >
>

[VOTE] Apache Maven 4.0.0-alpha-8 release

[Guillaume Nodet]

I'm starting a new vote to release this new alpha.

This alpha release provides new cornerstone features for the future Maven
evolution.
In particular, the POM model which was set in stone to a 4.0.0 version
since Maven 3.0, is now able to evolve. For modules that have a packaging
which is not POM, the flattened consumer POM is now installed/deployed
instead of the main POM, eventually translated back into a 4.0.0 model
version for consumer compatibility. The build POM is also installed /
deployed unchanged. This allows the introduction of the 4.1.0 model which
already brings a few improvements.

50 issues solved:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353356

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

Dev dist directory:
https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-8/

Source release checksums:
apache-maven-4.0.0-alpha-8-src.zip sha512:

7264b5ae1a567ff9249f8020bc5713386f26bdd297b499e309a70897d03b647ef5a1446d10963529fd50dbab0ee56f5357ab39405462b8a5326a99bae80222c9

apache-maven-4.0.0-alpha-8-src.tar.gz sha512:

d645e4015119836428e16bd5d4dd29bed6d4983d552445cdf587a61f0a2347a619e9de02cdc590eda000c4561e60e33e758aa83dca3d6243ede97f5be981b322


Binary release checksums:
apache-maven-4.0.0-alpha-8-bin.zip sha512:

6aa9486e2d880b691580e0071347022b6426f0a6b2c6549879b6a848a4494c70ff8dff25ffe8de2edd82583d7119bf359156ece0f9ef18f1c99ff3db776461f3

apache-maven-4.0.0-alpha-8-bin.tar.gz sha512:

7646b5bbaa0b81e600076055134ba88d5bd02d7a0ae03829b7e217aad9e47c25a3edbf4b091562d4bc9d93b5a50e84449a679f18052dc4f97d0314a8bc9dd961


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

Draft for release notes:
https://github.com/apache/maven-site/pull/462
https://github.com/apache/maven-site/blob/21deeaf4a0fc4993e0091d214f194195dc66c167/content/markdown/docs/4.0.0-alpha-8/release-notes.md

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

Note that this release has been built and uploaded with 4.0.0-alpha-8
itself, which means it uses the new build and consumer POMs...

Vote open for 72h

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

Cheers
Guillaume

[VOTE] Release Maven Dependency Plugin version 3.6.1

[Michael Osipov]

Hi,

we solved 7 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12353360

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

Staging repo:
https://repository.apache.org/content/repositories/maven-2013/
https://repository.apache.org/content/repositories/maven-2013/org/apache/maven/plugins/maven-dependency-plugin/3.6.1/maven-dependency-plugin-3.6.1-source-release.zip

Source release checksum(s):
maven-dependency-plugin-3.6.1-source-release.zip
sha512: 
6bdbd4cf4ff355d4e087ee5a7eef24b8812963c4372a6ba5116c8ea8dfdc5291c34edc262fe19eb2fc97a8e77d60c91d9ec843512729b862609f28689f396bd9


Staging site:
https://maven.apache.org/plugins-archives/maven-dependency-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

Re: Maven 5 pom extension for agents

[Benjamin Marwell]

All this discussion, but I honestly find the idea of mockito creating a
plugin like jacoco a cleaner solution. Are there any drawbacks? It worked
for a long time now.



On Fri, 20 Oct 2023, 22:00 Guillaume Nodet,  wrote:

> If false positives are a problem, we could just have an empty default
> value.
> Users would simply have to configure something like:
>net.bytebuddy:byte-buddy-agent
> Also, a special auto-discover value  (or another predefined value of
> course) could be used to discover agents in the test classpath and add them
> as agents automatically.
>
>
>
>
> Le ven. 20 oct. 2023 à 21:29, Romain Manni-Bucau  a
> écrit :
>
> > Guess we would get a lot of false positive and surefire already has it so
> > not sure it would help to simplify, complexity seems 1-1 :s
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 20 oct. 2023 à 21:05, Guillaume Nodet  a
> écrit
> > :
> >
> > > Not sure agents are widely used during the build either.
> > > I wonder if surefire should be given a list of artifacts coordinates
> that
> > > it would consider as agents if they are in the test class path...  The
> > > default value would contain bytebuddy, but it could be changed (and
> > ordered
> > > considered in that list) if needed.
> > > That would be very specific to surefire, but I'm not sure there are
> many
> > > use cases...
> > >
> > > Guillaume
> > >
> > > Le ven. 20 oct. 2023, 20:44, Romain Manni-Bucau  >
> > a
> > > écrit :
> > >
> > > > Can be the way to define the lookup, an heuristic will never work by
> > > > design...that said, on my side, not sure JPMS will be widely adopted
> > > > anytime soon so can be a false problem.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
> > > > henn...@schmiedehausen.org> a écrit :
> > > >
> > > > > I think we will need to start rethinking dependencies more. A
> similar
> > > > > problem exists with modules; the current heuristics to decide
> > whether a
> > > > > dependency goes on module path or classpath will start to become
> > > painful
> > > > in
> > > > > the very near future.
> > > > >
> > > > > -h
> > > > >
> > > > >
> > > > > On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell <
> > bmarw...@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > If you can still use it twice, works for me, too.
> > > > > >
> > > > > > Either way, you'd need it both as a dependency and as an agent.
> > > > > >
> > > > > > Another requirement Romain mentioned is the order of agent
> loading.
> > > > > Mockito
> > > > > > wants to be first, and others can come later.
> > > > > >
> > > > > > - Ben
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 18 Oct 2023, 00:11 Tamás Cservenák,  >
> > > > wrote:
> > > > > >
> > > > > > > What about type=java-agent? Basically a new ArtifactHandler?
> > > > > > >
> > > > > > > See https://maven.apache.org/repositories/artifacts.html
> > > > > > >
> > > > > > > T
> > > > > > >
> > > > > > > On Tue, Oct 17, 2023, 23:54 Benjamin Marwell <
> > bmarw...@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hey all,
> > > > > > > >
> > > > > > > > In a mockito issue, JDK maintainers suggested to
> differentiate
> > > > > between
> > > > > > > > agents and normal dependencies. Starting with JDK 21 already,
> > > this
> > > > > > makes
> > > > > > > a
> > > > > > > > lot of sense: dynamic loading of agents will be a no-go.
> > > > > > > >
> > > > > > > > One suggestion was:
> > > > > > > >
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ...
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ...
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > >
> > > > > > > > Not sure if this is the best way, but this is something
> similar
> > > > might
> > > > > > be
> > > > > > > > needed.
> > > > > > > > Currently, the only way to handle agents is to add them
> > manually
> > > to
> > > > > the
> > > > > > > > surefire argLine. To make things worse, a deoendency goal is
> > > needed
> > > > > > until
> > > > > > > > Romains PR is merged:
> > > > > > > > https://github.com/apache/maven/pull/1281
> > > > > > > >
> > > > > > > > Another issue is that 

Re: Maven 5 pom extension for agents

[Guillaume Nodet]

If false positives are a problem, we could just have an empty default value.
Users would simply have to configure something like:
   net.bytebuddy:byte-buddy-agent
Also, a special auto-discover value  (or another predefined value of
course) could be used to discover agents in the test classpath and add them
as agents automatically.




Le ven. 20 oct. 2023 à 21:29, Romain Manni-Bucau  a
écrit :

> Guess we would get a lot of false positive and surefire already has it so
> not sure it would help to simplify, complexity seems 1-1 :s
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 20 oct. 2023 à 21:05, Guillaume Nodet  a écrit
> :
>
> > Not sure agents are widely used during the build either.
> > I wonder if surefire should be given a list of artifacts coordinates that
> > it would consider as agents if they are in the test class path...  The
> > default value would contain bytebuddy, but it could be changed (and
> ordered
> > considered in that list) if needed.
> > That would be very specific to surefire, but I'm not sure there are many
> > use cases...
> >
> > Guillaume
> >
> > Le ven. 20 oct. 2023, 20:44, Romain Manni-Bucau 
> a
> > écrit :
> >
> > > Can be the way to define the lookup, an heuristic will never work by
> > > design...that said, on my side, not sure JPMS will be widely adopted
> > > anytime soon so can be a false problem.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
> > > henn...@schmiedehausen.org> a écrit :
> > >
> > > > I think we will need to start rethinking dependencies more. A similar
> > > > problem exists with modules; the current heuristics to decide
> whether a
> > > > dependency goes on module path or classpath will start to become
> > painful
> > > in
> > > > the very near future.
> > > >
> > > > -h
> > > >
> > > >
> > > > On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell <
> bmarw...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > If you can still use it twice, works for me, too.
> > > > >
> > > > > Either way, you'd need it both as a dependency and as an agent.
> > > > >
> > > > > Another requirement Romain mentioned is the order of agent loading.
> > > > Mockito
> > > > > wants to be first, and others can come later.
> > > > >
> > > > > - Ben
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, 18 Oct 2023, 00:11 Tamás Cservenák, 
> > > wrote:
> > > > >
> > > > > > What about type=java-agent? Basically a new ArtifactHandler?
> > > > > >
> > > > > > See https://maven.apache.org/repositories/artifacts.html
> > > > > >
> > > > > > T
> > > > > >
> > > > > > On Tue, Oct 17, 2023, 23:54 Benjamin Marwell <
> bmarw...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > Hey all,
> > > > > > >
> > > > > > > In a mockito issue, JDK maintainers suggested to differentiate
> > > > between
> > > > > > > agents and normal dependencies. Starting with JDK 21 already,
> > this
> > > > > makes
> > > > > > a
> > > > > > > lot of sense: dynamic loading of agents will be a no-go.
> > > > > > >
> > > > > > > One suggestion was:
> > > > > > >
> > > > > > > 
> > > > > > > 
> > > > > > > ...
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ...
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > >
> > > > > > > Not sure if this is the best way, but this is something similar
> > > might
> > > > > be
> > > > > > > needed.
> > > > > > > Currently, the only way to handle agents is to add them
> manually
> > to
> > > > the
> > > > > > > surefire argLine. To make things worse, a deoendency goal is
> > needed
> > > > > until
> > > > > > > Romains PR is merged:
> > > > > > > https://github.com/apache/maven/pull/1281
> > > > > > >
> > > > > > > Another issue is that a parent pom might not be able to easily
> > > define
> > > > > > this
> > > > > > > option. There were some concerns that part of the configuration
> > > > needed
> > > > > to
> > > > > > > be repeated in every module.
> > > > > > >
> > > > > > > So, I wrote Maven 5.
> > > > > > > Maven 4 is the stepping stone to the build/consumer pom. But
> this
> > > is
> > > > an
> > > > > > > extension. Not really a breaking change in terms of parsing,
> but
> > in
> > > > > terms
> > > > > > > of building a project. Thus, it should go 

Re: Parallelising custom plugin (rust-maven-plugin)

[Adam Cimarosti]

I don't think I can really split things into a different modile as the
plugin writes binaries to the /target/classes directory for inclusion in
the jar file.

Could you go into more details on what would be involved in a custom life
cycle?

Would you have some pointers for this (class names, docs, examples)? It
exceeds my Maven-fu ;-).

Thanks,
Adam


On Fri, 20 Oct 2023, 20:32 Romain Manni-Bucau, 
wrote:

> Hi,
>
> did you try splitting rust and java code in 2 modules and using
> -T$something ? would do it, otherwise you probably need to write an
> extension which will capture compiler config, make it skipped to replace it
> but a custom lifecycle management in your own plugin but looks more
> complicated to achieve this goal.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 20 oct. 2023 à 21:28, Adam Cimarosti  a
> écrit :
>
> > Hello,
> >
> > I am the author of the rust-maven-plugin (
> > https://github.com/questdb/rust-maven-plugin/).
> >
> > We use this plugin ourselves at QuestDB and in CI `mvn compile` takes
> > around 8 minutes.
> >
> > It appears that the Java and Rust builds happen serially.
> >
> > Is there a way to parallelise things so our plugin kicks off building
> Rust
> > in parallel while the Kava code is building?
> >
> > Your advice is much appreciated!
> >
> > Thanks,
> > Adam
> >
>

[VOTE] Release Maven JXR version 3.3.1

[Michael Osipov]

Hi,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527=12352247

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

Staging repo:
https://repository.apache.org/content/repositories/maven-2012/
https://repository.apache.org/content/repositories/maven-2012/org/apache/maven/jxr/jxr/3.3.1/jxr-3.3.1-source-release.zip

Source release checksum(s):
jxr-3.3.1-source-release.zip
sha512: 
f200a1b11c4b3bd00c3f9d3dc47a17f3e475c118abb6e4598a15bfacda0672d297f24dd2426bb4b1f0af711361a930431dc73ad7518ce3dd3a01793864893a50


Staging site:
https://maven.apache.org/jxr-archives/jxr-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

[ANN] Apache Maven Plugin Tools 3.10.1 released

[Michael Osipov]

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


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


Release Notes - Maven Plugin Tools - Version 3.10.1

** Bug
* [MPLUGIN-482] - JavadocSite.createLink() does not consider 
implicit module path prefix


** Improvement
* [MPLUGIN-442] - Rewrite plugin goal documentation generation to 
use supplied sink instead of direct Xdoc

* [MPLUGIN-475] - Upgrade to plexus-utils / plexus-xml 4.0.0
* [MPLUGIN-477] - Don't add a stray period

** Dependency upgrade
* [MPLUGIN-478] - Upgrade org.junit:junit-bom from 5.9.3 to 5.10.0
* [MPLUGIN-479] - Bump org.codehaus.plexus:plexus-archiver from 
4.7.1 to 4.8.0



Enjoy,

-The Apache Maven team

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

Re: Parallelising custom plugin (rust-maven-plugin)

[Romain Manni-Bucau]

Hi,

did you try splitting rust and java code in 2 modules and using
-T$something ? would do it, otherwise you probably need to write an
extension which will capture compiler config, make it skipped to replace it
but a custom lifecycle management in your own plugin but looks more
complicated to achieve this goal.

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



Le ven. 20 oct. 2023 à 21:28, Adam Cimarosti  a écrit :

> Hello,
>
> I am the author of the rust-maven-plugin (
> https://github.com/questdb/rust-maven-plugin/).
>
> We use this plugin ourselves at QuestDB and in CI `mvn compile` takes
> around 8 minutes.
>
> It appears that the Java and Rust builds happen serially.
>
> Is there a way to parallelise things so our plugin kicks off building Rust
> in parallel while the Kava code is building?
>
> Your advice is much appreciated!
>
> Thanks,
> Adam
>

Parallelising custom plugin (rust-maven-plugin)

[Adam Cimarosti]

Hello,

I am the author of the rust-maven-plugin (
https://github.com/questdb/rust-maven-plugin/).

We use this plugin ourselves at QuestDB and in CI `mvn compile` takes
around 8 minutes.

It appears that the Java and Rust builds happen serially.

Is there a way to parallelise things so our plugin kicks off building Rust
in parallel while the Kava code is building?

Your advice is much appreciated!

Thanks,
Adam

Re: Maven 5 pom extension for agents

[Romain Manni-Bucau]

Guess we would get a lot of false positive and surefire already has it so
not sure it would help to simplify, complexity seems 1-1 :s

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



Le ven. 20 oct. 2023 à 21:05, Guillaume Nodet  a écrit :

> Not sure agents are widely used during the build either.
> I wonder if surefire should be given a list of artifacts coordinates that
> it would consider as agents if they are in the test class path...  The
> default value would contain bytebuddy, but it could be changed (and ordered
> considered in that list) if needed.
> That would be very specific to surefire, but I'm not sure there are many
> use cases...
>
> Guillaume
>
> Le ven. 20 oct. 2023, 20:44, Romain Manni-Bucau  a
> écrit :
>
> > Can be the way to define the lookup, an heuristic will never work by
> > design...that said, on my side, not sure JPMS will be widely adopted
> > anytime soon so can be a false problem.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
> > henn...@schmiedehausen.org> a écrit :
> >
> > > I think we will need to start rethinking dependencies more. A similar
> > > problem exists with modules; the current heuristics to decide whether a
> > > dependency goes on module path or classpath will start to become
> painful
> > in
> > > the very near future.
> > >
> > > -h
> > >
> > >
> > > On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell  >
> > > wrote:
> > >
> > > > If you can still use it twice, works for me, too.
> > > >
> > > > Either way, you'd need it both as a dependency and as an agent.
> > > >
> > > > Another requirement Romain mentioned is the order of agent loading.
> > > Mockito
> > > > wants to be first, and others can come later.
> > > >
> > > > - Ben
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, 18 Oct 2023, 00:11 Tamás Cservenák, 
> > wrote:
> > > >
> > > > > What about type=java-agent? Basically a new ArtifactHandler?
> > > > >
> > > > > See https://maven.apache.org/repositories/artifacts.html
> > > > >
> > > > > T
> > > > >
> > > > > On Tue, Oct 17, 2023, 23:54 Benjamin Marwell 
> > > > wrote:
> > > > >
> > > > > > Hey all,
> > > > > >
> > > > > > In a mockito issue, JDK maintainers suggested to differentiate
> > > between
> > > > > > agents and normal dependencies. Starting with JDK 21 already,
> this
> > > > makes
> > > > > a
> > > > > > lot of sense: dynamic loading of agents will be a no-go.
> > > > > >
> > > > > > One suggestion was:
> > > > > >
> > > > > > 
> > > > > > 
> > > > > > ...
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ...
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >
> > > > > > Not sure if this is the best way, but this is something similar
> > might
> > > > be
> > > > > > needed.
> > > > > > Currently, the only way to handle agents is to add them manually
> to
> > > the
> > > > > > surefire argLine. To make things worse, a deoendency goal is
> needed
> > > > until
> > > > > > Romains PR is merged:
> > > > > > https://github.com/apache/maven/pull/1281
> > > > > >
> > > > > > Another issue is that a parent pom might not be able to easily
> > define
> > > > > this
> > > > > > option. There were some concerns that part of the configuration
> > > needed
> > > > to
> > > > > > be repeated in every module.
> > > > > >
> > > > > > So, I wrote Maven 5.
> > > > > > Maven 4 is the stepping stone to the build/consumer pom. But this
> > is
> > > an
> > > > > > extension. Not really a breaking change in terms of parsing, but
> in
> > > > terms
> > > > > > of building a project. Thus, it should go onto the roadmap.
> > > > > >
> > > > > > ... unless you want to keep the current status quo, which is also
> > an
> > > > > > option. But before making an argument here, I'd recommend reading
> > the
> > > > > > lengthy (sorry!) discussion on the mockito issue tracker. Since
> > Karl
> > > > > Heinz
> > > > > > started the issue, I'd love to hear back from you, too. Link:
> > > > > > https://github.com/mockito/mockito/issues/3037
> > > > > >
> > > > > > If no discussion is needed at this point, let's keep this as a
> > > reminder
> > > > > for
> > > > > > the next Apero and/or Maven 5 then.
> > > > > >
> > > > > > - Ben
> > > > > >
> > > > >
> > > >
> > >
> >
>

[RESULT] [VOTE] Release Maven Plugin Tools version 3.10.1

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Hervé Boutemy, Tamás Cservenák, Slawomir Jaranowski, 
Romain Manni-Bucau


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

Re: [VOTE] Release Maven Plugin Tools version 3.10.1

[Michael Osipov]

If necessary, spawn a new issue to further discuss this. I will continue 
with the release meanwhile...


Am 2023-10-20 um 17:51 schrieb Konrad Windszus:

Hi everyone,
Sorry for the late response.
Those changes were done deliberate due to what Michael said before.
Should have mentioned that before.
Does this require a dedicated JIRA with description or is it fine to improve 
the semantics like this silently (I fail to see any functional impact here 
apart from the colouring)?

Konrad


On 19. Oct 2023, at 09:20, Michael Osipov  wrote:

Went through the two cases, I believe that they are fine (or more logical than 
before):

1. Change in link style:
before:


fast



after:


  fast



Definition of  says [1]: A few other elements belong to this category, 
but only if a specific condition is fulfilled:

, if it contains only phrasing content

I don't know wether this applies. I'd rather format the link than the code with 
link, like done now.

2. No link highlight of target anchors:before:


  


  excludeDefaultDirectories

  
...


after:



  

  excludeDefaultDirectories


  

...

Previously, the anchor (where we jump to) was highlighted although it does not 
jump anywhere. I'd expect to highlight if you want to jump somewhere and not 
from.

Note that with the Doxia 2.0.0 stack it will further simplify and we will 
review this again.

Konrad, maybe you want to add some words?

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/code

-
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




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

Re: Maven 5 pom extension for agents

[Guillaume Nodet]

Not sure agents are widely used during the build either.
I wonder if surefire should be given a list of artifacts coordinates that
it would consider as agents if they are in the test class path...  The
default value would contain bytebuddy, but it could be changed (and ordered
considered in that list) if needed.
That would be very specific to surefire, but I'm not sure there are many
use cases...

Guillaume

Le ven. 20 oct. 2023, 20:44, Romain Manni-Bucau  a
écrit :

> Can be the way to define the lookup, an heuristic will never work by
> design...that said, on my side, not sure JPMS will be widely adopted
> anytime soon so can be a false problem.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
> henn...@schmiedehausen.org> a écrit :
>
> > I think we will need to start rethinking dependencies more. A similar
> > problem exists with modules; the current heuristics to decide whether a
> > dependency goes on module path or classpath will start to become painful
> in
> > the very near future.
> >
> > -h
> >
> >
> > On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell 
> > wrote:
> >
> > > If you can still use it twice, works for me, too.
> > >
> > > Either way, you'd need it both as a dependency and as an agent.
> > >
> > > Another requirement Romain mentioned is the order of agent loading.
> > Mockito
> > > wants to be first, and others can come later.
> > >
> > > - Ben
> > >
> > >
> > >
> > >
> > > On Wed, 18 Oct 2023, 00:11 Tamás Cservenák, 
> wrote:
> > >
> > > > What about type=java-agent? Basically a new ArtifactHandler?
> > > >
> > > > See https://maven.apache.org/repositories/artifacts.html
> > > >
> > > > T
> > > >
> > > > On Tue, Oct 17, 2023, 23:54 Benjamin Marwell 
> > > wrote:
> > > >
> > > > > Hey all,
> > > > >
> > > > > In a mockito issue, JDK maintainers suggested to differentiate
> > between
> > > > > agents and normal dependencies. Starting with JDK 21 already, this
> > > makes
> > > > a
> > > > > lot of sense: dynamic loading of agents will be a no-go.
> > > > >
> > > > > One suggestion was:
> > > > >
> > > > > 
> > > > > 
> > > > > ...
> > > > > 
> > > > > 
> > > > > 
> > > > > ...
> > > > > 
> > > > > 
> > > > > 
> > > > >
> > > > > Not sure if this is the best way, but this is something similar
> might
> > > be
> > > > > needed.
> > > > > Currently, the only way to handle agents is to add them manually to
> > the
> > > > > surefire argLine. To make things worse, a deoendency goal is needed
> > > until
> > > > > Romains PR is merged:
> > > > > https://github.com/apache/maven/pull/1281
> > > > >
> > > > > Another issue is that a parent pom might not be able to easily
> define
> > > > this
> > > > > option. There were some concerns that part of the configuration
> > needed
> > > to
> > > > > be repeated in every module.
> > > > >
> > > > > So, I wrote Maven 5.
> > > > > Maven 4 is the stepping stone to the build/consumer pom. But this
> is
> > an
> > > > > extension. Not really a breaking change in terms of parsing, but in
> > > terms
> > > > > of building a project. Thus, it should go onto the roadmap.
> > > > >
> > > > > ... unless you want to keep the current status quo, which is also
> an
> > > > > option. But before making an argument here, I'd recommend reading
> the
> > > > > lengthy (sorry!) discussion on the mockito issue tracker. Since
> Karl
> > > > Heinz
> > > > > started the issue, I'd love to hear back from you, too. Link:
> > > > > https://github.com/mockito/mockito/issues/3037
> > > > >
> > > > > If no discussion is needed at this point, let's keep this as a
> > reminder
> > > > for
> > > > > the next Apero and/or Maven 5 then.
> > > > >
> > > > > - Ben
> > > > >
> > > >
> > >
> >
>

[VOTE] Release Maven Surefire version 3.2.1

[Michael Osipov]

Hi,

we solved 9 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353730

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

Staging repo:
https://repository.apache.org/content/repositories/maven-2010/
https://repository.apache.org/content/repositories/maven-2010/org/apache/maven/surefire/surefire/3.2.1/surefire-3.2.1-source-release.zip

Source release checksum(s):
surefire-3.2.1-source-release.zip
sha512: 
749f75cc372c020eb25344eee839b4935954a1b0deb3f88bbcee7846f25fd51e10d5417860c480dbae7baecf7ca5af18b268ecc449f487c205991649ab5ff470


Staging site:
https://maven.apache.org/surefire-archives/surefire-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

Re: Maven 5 pom extension for agents

[Romain Manni-Bucau]

Can be the way to define the lookup, an heuristic will never work by
design...that said, on my side, not sure JPMS will be widely adopted
anytime soon so can be a false problem.

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



Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
henn...@schmiedehausen.org> a écrit :

> I think we will need to start rethinking dependencies more. A similar
> problem exists with modules; the current heuristics to decide whether a
> dependency goes on module path or classpath will start to become painful in
> the very near future.
>
> -h
>
>
> On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell 
> wrote:
>
> > If you can still use it twice, works for me, too.
> >
> > Either way, you'd need it both as a dependency and as an agent.
> >
> > Another requirement Romain mentioned is the order of agent loading.
> Mockito
> > wants to be first, and others can come later.
> >
> > - Ben
> >
> >
> >
> >
> > On Wed, 18 Oct 2023, 00:11 Tamás Cservenák,  wrote:
> >
> > > What about type=java-agent? Basically a new ArtifactHandler?
> > >
> > > See https://maven.apache.org/repositories/artifacts.html
> > >
> > > T
> > >
> > > On Tue, Oct 17, 2023, 23:54 Benjamin Marwell 
> > wrote:
> > >
> > > > Hey all,
> > > >
> > > > In a mockito issue, JDK maintainers suggested to differentiate
> between
> > > > agents and normal dependencies. Starting with JDK 21 already, this
> > makes
> > > a
> > > > lot of sense: dynamic loading of agents will be a no-go.
> > > >
> > > > One suggestion was:
> > > >
> > > > 
> > > > 
> > > > ...
> > > > 
> > > > 
> > > > 
> > > > ...
> > > > 
> > > > 
> > > > 
> > > >
> > > > Not sure if this is the best way, but this is something similar might
> > be
> > > > needed.
> > > > Currently, the only way to handle agents is to add them manually to
> the
> > > > surefire argLine. To make things worse, a deoendency goal is needed
> > until
> > > > Romains PR is merged:
> > > > https://github.com/apache/maven/pull/1281
> > > >
> > > > Another issue is that a parent pom might not be able to easily define
> > > this
> > > > option. There were some concerns that part of the configuration
> needed
> > to
> > > > be repeated in every module.
> > > >
> > > > So, I wrote Maven 5.
> > > > Maven 4 is the stepping stone to the build/consumer pom. But this is
> an
> > > > extension. Not really a breaking change in terms of parsing, but in
> > terms
> > > > of building a project. Thus, it should go onto the roadmap.
> > > >
> > > > ... unless you want to keep the current status quo, which is also an
> > > > option. But before making an argument here, I'd recommend reading the
> > > > lengthy (sorry!) discussion on the mockito issue tracker. Since Karl
> > > Heinz
> > > > started the issue, I'd love to hear back from you, too. Link:
> > > > https://github.com/mockito/mockito/issues/3037
> > > >
> > > > If no discussion is needed at this point, let's keep this as a
> reminder
> > > for
> > > > the next Apero and/or Maven 5 then.
> > > >
> > > > - Ben
> > > >
> > >
> >
>

Re: [VOTE] Retire Maven Docck Plugin

[Henning Schmiedehausen]

+1

-h

On Mon, Oct 16, 2023 at 3:50 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> - Last release was in 2015
> - use Maven 2.2.1
> - we have a Maven Plugin Tools - which should be one project for build and
> check Maven plugins
> - no active development ...
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MDOCCK%20AND%20(%20resolution%20%3D%20Unresolved%20OR%20fixVersion%20%3D%203.0.0)
> - no working with current plugins
>
> I therefore propose that we retire maven-docck-plugin -
> https://maven.apache.org/plugins/maven-docck-plugin/
>
> If this vote is successful I will make one final release of the plugin,
> making it clear on the plugin site that it has been retired.
> After that the source code will be moved into read-only mode.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
> [1]
>
> --
> Sławomir Jaranowski
>

Re: Maven 5 pom extension for agents

[Henning Schmiedehausen]

I think we will need to start rethinking dependencies more. A similar
problem exists with modules; the current heuristics to decide whether a
dependency goes on module path or classpath will start to become painful in
the very near future.

-h


On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell 
wrote:

> If you can still use it twice, works for me, too.
>
> Either way, you'd need it both as a dependency and as an agent.
>
> Another requirement Romain mentioned is the order of agent loading. Mockito
> wants to be first, and others can come later.
>
> - Ben
>
>
>
>
> On Wed, 18 Oct 2023, 00:11 Tamás Cservenák,  wrote:
>
> > What about type=java-agent? Basically a new ArtifactHandler?
> >
> > See https://maven.apache.org/repositories/artifacts.html
> >
> > T
> >
> > On Tue, Oct 17, 2023, 23:54 Benjamin Marwell 
> wrote:
> >
> > > Hey all,
> > >
> > > In a mockito issue, JDK maintainers suggested to differentiate between
> > > agents and normal dependencies. Starting with JDK 21 already, this
> makes
> > a
> > > lot of sense: dynamic loading of agents will be a no-go.
> > >
> > > One suggestion was:
> > >
> > > 
> > > 
> > > ...
> > > 
> > > 
> > > 
> > > ...
> > > 
> > > 
> > > 
> > >
> > > Not sure if this is the best way, but this is something similar might
> be
> > > needed.
> > > Currently, the only way to handle agents is to add them manually to the
> > > surefire argLine. To make things worse, a deoendency goal is needed
> until
> > > Romains PR is merged:
> > > https://github.com/apache/maven/pull/1281
> > >
> > > Another issue is that a parent pom might not be able to easily define
> > this
> > > option. There were some concerns that part of the configuration needed
> to
> > > be repeated in every module.
> > >
> > > So, I wrote Maven 5.
> > > Maven 4 is the stepping stone to the build/consumer pom. But this is an
> > > extension. Not really a breaking change in terms of parsing, but in
> terms
> > > of building a project. Thus, it should go onto the roadmap.
> > >
> > > ... unless you want to keep the current status quo, which is also an
> > > option. But before making an argument here, I'd recommend reading the
> > > lengthy (sorry!) discussion on the mockito issue tracker. Since Karl
> > Heinz
> > > started the issue, I'd love to hear back from you, too. Link:
> > > https://github.com/mockito/mockito/issues/3037
> > >
> > > If no discussion is needed at this point, let's keep this as a reminder
> > for
> > > the next Apero and/or Maven 5 then.
> > >
> > > - Ben
> > >
> >
>

Re: [VOTE] Release Maven Plugin Tools version 3.10.1

[Konrad Windszus]

Hi everyone,
Sorry for the late response.
Those changes were done deliberate due to what Michael said before.
Should have mentioned that before.
Does this require a dedicated JIRA with description or is it fine to improve 
the semantics like this silently (I fail to see any functional impact here 
apart from the colouring)?

Konrad

> On 19. Oct 2023, at 09:20, Michael Osipov  wrote:
> 
> Went through the two cases, I believe that they are fine (or more logical 
> than before):
> 
> 1. Change in link style:
> before:
>> 
>> fast
>> 
> 
> after:
>> 
>>  fast
>> 
> 
> Definition of  says [1]: A few other elements belong to this category, 
> but only if a specific condition is fulfilled:
> 
>, if it contains only phrasing content
> 
> I don't know wether this applies. I'd rather format the link than the code 
> with link, like done now.
> 
> 2. No link highlight of target anchors:before:
>> 
>>  
>>
>>
>>  > name="excludeDefaultDirectories">excludeDefaultDirectories
>>
>>  
>> ...
> 
> after:
> 
> 
>>  
>>
>>  > name="a.3CexcludeDefaultDirectories.3E">excludeDefaultDirectories
>>
>>
>>  
> ...
> 
> Previously, the anchor (where we jump to) was highlighted although it does 
> not jump anywhere. I'd expect to highlight if you want to jump somewhere and 
> not from.
> 
> Note that with the Doxia 2.0.0 stack it will further simplify and we will 
> review this again.
> 
> Konrad, maybe you want to add some words?
> 
> [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/code
> 
> -
> 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

JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up

[David Delabassee]

Greetings!

JDK 21 has been released (General Availability) on September 19th as planned. 
You can find "The Arrival of Java 21" announcement here [1], and some 
additional Java 21 materials in the "Topics of Interest" section below. On 
behalf of the entire Java team, let me send our thanks to all of you. Through 
your active participation in this program, you are helping shape the Java 
platform!

Needless to say, that Java 21 is an important release, so may I ask you to send 
me a brief email with the Java 21 support status of your project(s): Already 
supported - Plan to support short-term - Don't plan to support short-term ?

And now that JDK 21 is out, let's shift our attention to JDK 22 which will 
enter the Rampdown Phase in less than 50 days on December 7 [2].

I want to conclude this update by briefly mentioning three different 
initiatives to are relevant to this group as they are, in their own way and at 
various levels, contributing to adopt newer Java releases more rapidly: the 
Class-File API, Oracle's Java Platform extension for VS Code, and the Java 
Playground.

### The Class-File API

The Class-File API is a new standard API for parsing, generating, and 
transforming Java class files. One of its unique aspects is that it will 
co-evolve with the class-file format, which overtime will greatly reduce the 
friction of implementing new class-file features. With the fast-paced evolution 
of the Java platform, this was much-needed. This API should soon be previewed 
and as it matures, we expect the JDK to switch from using various custom 
class-file libraries to this standard API. We also expect that overtime 
frameworks relying on bytecode manipulation will also benefit from using this 
new JDK class-file library. For more information, please check this recent 
Newscast [3] for an overview, Brian Goetz's JVMLS session [4] for more details 
and design considerations, and JEP 457: Class-File API (Preview) [5] for the 
technical details.

### Oracle's Java Platform extension for Visual Studio Code

Oracle has just announced [6] a new Visual Studio Code extension for Java 
developers. Unlike other VS Code extensions, this new extension is using under 
the hood the `javac` compiler for code editing and compilation, and OpenJDK's 
debugger interface for debugging. This enables us to offer VS Code IDE support 
for new JDK features as soon as they are introduced, even during JDK Early 
Access phases. To this effect, this VS Code Extension will support the current 
JDK releases as well as the next upcoming JDK version. For more information, 
please check the announcement [6].

### The Java Playground

The Java Playground [7] is an online sandbox that helps testing and exploring 
new Java language features. No setup required, just type your Java snippet in 
your browser and run it! Right now, the Playground is using Java 21 with 
Preview Features enabled, and it will switch to a new Java version as soon as 
there is a new Java language features integrated in OpenJDK Early-Access 
builds. The Playground is focusing mostly on Project Amber and is certainly not 
mean to be some sort of a lightweight online-IDE, it is instead a learning tool 
to play with new Java language feature shortly after they have been integrated 
into the platform.

[1] https://inside.java/2023/09/19/the-arrival-of-java-21/
[2] https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008269.html
[3] https://www.youtube.com/watch?v=bQ2Rwpyj_Ks
[4] https://www.youtube.com/watch?v=pcg-E_qyMOI
[5] https://openjdk.org/jeps/457
[6] https://inside.java/2023/10/18/announcing-vscode-extension/
[7] https://dev.java/playground


## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change

As discussed in the July 2023 Quality Outreach update [8], starting in JDK 21 
javac emits a note if _implicit_ annotation processing is being used, that is, 
if one or more annotation processors are found and run from the class path when 
no explicit annotation processing configuration options are used.

The note is reported since, quoting from the note text: "A future release of 
javac may disable annotation processing unless at least one processor is 
specified by name (-processor), or a search path is specified 
(--processor-path, --processor-module-path), or annotation processing is 
enabled explicitly (-proc:only, -proc:full)."

That future version of javac has arrived in JDK 22 b19+ with JDK-8306819 
("Consider disabling the compiler's default active annotation processing"). In 
the situation where a note was emitted in JDK 21, in JDK 22 no note is emitted, 
and annotation processors are *not* run. To restore the previous behavior with 
respect to running annotation processors, add the '-proc:full' javac option.

Feedback on the annotation processing policy change can be sent to compiler-dev 
[9].

[8] https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html
[9] https://mail.openjdk.org/mailman/listinfo/compiler-dev


## JDK 

Re: Do we have a list for changes between 3.9 and 4.0?

[Guillaume Nodet]

Fwiw, I've done a bit of cleanup on this list to remove fixVersion in
version such as 4.0.x-candidate, backlog, issues to be reviewed.  If the
issue has been fixed, it should be in a release...
The full list of changes between 3.9.x and master looks like the following:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%204.0.0%20AND%20NOT%20fixVersion%20in%20(3.8.0%2C%203.8.1%2C%203.8.2%2C%203.8.3%2C%203.8.4%2C%203.8.5%2C%203.8.6%2C%203.8.7%2C%203.8.8%2C%203.8.9%2C%203.9.0%2C%203.9.1%2C%203.9.2%2C%203.9.3%2C%203.9.4%2C%203.9.5)

There are also a couple of issues that have been marked as resolved in
4.0.0 but in no release and should be flagged with a correct release imho:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20in%20(4.0.0)%20AND%20NOT%20fixVersion%20in%20(4.0.0-alpha-1%2C%204.0.0-alpha-2%2C%204.0.0-alpha-3%2C%204.0.0-alpha-4%2C%204.0.0-alpha-5%2C%204.0.0-alpha-7%2C%204.0.0-alpha-8)

Guillaume

Le ven. 20 oct. 2023 à 09:27, Tamás Cservenák  a
écrit :

> Howdy,
>
> something ike this?
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20in%20(4.0.0%2C%204.0.0-alpha-8%2C%204.0.x-candidate%2C%20%224.x%20%2F%20Backlog%22%2C%20%22Issues%20to%20be%20reviewed%20for%204.x%22%2C%204.0.0-alpha-2%2C%204.0.0-alpha-3%2C%204.0.0-alpha-4%2C%204.0.0-alpha-5%2C%204.0.0-alpha-7)
>
> HTH
> T
>
> On Fri, Oct 20, 2023 at 9:22 AM tison  wrote:
>
> > I saw somewhat
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12346477
> > now.
> >
> > Best,
> > tison.
> >
> >
> > tison  于2023年10月16日周一 13:52写道：
> >
> > > Hi,
> > >
> > > I'm going to try out the 4.0 branch, and I would like to have a list of
> > > important changes. Currently, each alpha version has its release note,
> > but
> > > that's like a log instead of a somewhat migration guide.
> > >
> > > Do we have an up-to-date list of changes between 3.9 and 4.0?
> > >
> > > Best,
> > > tison.
> > >
> >
>


-- 

Guillaume Nodet

Re: Do we have a list for changes between 3.9 and 4.0?

[Tamás Cservenák]

Howdy,

something ike this?
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20in%20(4.0.0%2C%204.0.0-alpha-8%2C%204.0.x-candidate%2C%20%224.x%20%2F%20Backlog%22%2C%20%22Issues%20to%20be%20reviewed%20for%204.x%22%2C%204.0.0-alpha-2%2C%204.0.0-alpha-3%2C%204.0.0-alpha-4%2C%204.0.0-alpha-5%2C%204.0.0-alpha-7)

HTH
T

On Fri, Oct 20, 2023 at 9:22 AM tison  wrote:

> I saw somewhat
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12346477
> now.
>
> Best,
> tison.
>
>
> tison  于2023年10月16日周一 13:52写道：
>
> > Hi,
> >
> > I'm going to try out the 4.0 branch, and I would like to have a list of
> > important changes. Currently, each alpha version has its release note,
> but
> > that's like a log instead of a somewhat migration guide.
> >
> > Do we have an up-to-date list of changes between 3.9 and 4.0?
> >
> > Best,
> > tison.
> >
>

Re: Do we have a list for changes between 3.9 and 4.0?

[tison]

I saw somewhat
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12346477
now.

Best,
tison.


tison  于2023年10月16日周一 13:52写道：

> Hi,
>
> I'm going to try out the 4.0 branch, and I would like to have a list of
> important changes. Currently, each alpha version has its release note, but
> that's like a log instead of a somewhat migration guide.
>
> Do we have an up-to-date list of changes between 3.9 and 4.0?
>
> Best,
> tison.
>