Re: [VOTE] - Release Apache Maven Shade Plugin Version 3.3.0

[Sylwester Lachiewicz]

+1

pon., 28 mar 2022, 18:29 użytkownik Karl Heinz Marbaise 
napisał:

> +1
> from me.
>
> kind regards
> Karl Heinz Marbaise
> On 24.03.22 19:21, Karl Heinz Marbaise wrote:
> > Hi,
> >
> > We solved 16 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12348391=Text
> >
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> >
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1730
> >
> >
> https://repository.apache.org/service/local/repositories/maven-1730/content/org/apache/maven/plugins/maven-shade-plugin/3.3.0/maven-shade-plugin-3.3.0-source-release.zip
> >
> >
> > Source release checksum(s):
> > maven-shade-plugin-3.3.0-source-release.zip sha512:
> >
> f88196508ca14442c7b6e6cf8e09b9e6d5ad7139e5c95d27b4f0ae390c4339277248ded7ddef5fd43151b9bc6abaaab6157d478fe4a73f941004cb8429bbfefd
> >
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-shade-plugin-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
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > 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 Shade Plugin Version 3.3.0

[Olivier Lamy]

+1

On Fri, 25 Mar 2022 at 04:21, Karl Heinz Marbaise  wrote:

> Hi,
>
> We solved 16 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12348391=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1730
>
>
> https://repository.apache.org/service/local/repositories/maven-1730/content/org/apache/maven/plugins/maven-shade-plugin/3.3.0/maven-shade-plugin-3.3.0-source-release.zip
>
> Source release checksum(s):
> maven-shade-plugin-3.3.0-source-release.zip sha512:
>
> f88196508ca14442c7b6e6cf8e09b9e6d5ad7139e5c95d27b4f0ae390c4339277248ded7ddef5fd43151b9bc6abaaab6157d478fe4a73f941004cb8429bbfefd
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-plugin-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
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] New Maven Core API for 4.x

[Matt Benson]

As a developer I appreciate the concept of immutability. At the same time,
having written more than one (proprietary) plugin that mutates the project
model, I would hate to see my options in this regard diminished
particularly if the future situation were one that forces me to modify the
Maven installation in order to achieve X result. Such a "trapdoor" as you
have suggested (to provide a managed mechanism for updating the project
model--presumably this would enable the core engine to be aware of changes)
would hopefully be a sufficient "method of last resort" to permit me to
keep a given plugin "modern" while still performing its essential duties.

Matt

On Mon, Mar 28, 2022, 12:30 PM Guillaume Nodet  wrote:

> What I have in mind is that plugins that use the new api would receive the
> immutable model, while plugins that use the old (3.x) api would receive a
> model that would wrap the immutable one. However, I think mutating the
> model or the maven project should be done via services provided by the
> maven api. That will allow controlling concurrent access, interception,
> logging, etc...
> For example, adding a source directory in the new api is done using the
> ProjectManager, which I think should be the place where the project is
> mutated:
>
>
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectManager.java
> I assume the number of plugins that mutate the project is small.  I think
> the best way would be to provide atomic apis for mutating the parts that
> need to be so that maven can have tighter control, but we can always
> provide an api to replace the Project or the Model with a new copy if
> needed so that any plugin can have the possibility to mutate those.
> Does that make sense?
>
> Guillaume
>
> Le lun. 28 mars 2022 à 13:47, Matt Benson  a écrit :
>
> > So in the new API, what kind of component would receive a mutable model
> if
> > not a plugin? I.e., what would be the correct mechanism for enhancing the
> > project model at runtime?
> >
> > Matt
> >
> > On Mon, Mar 28, 2022, 4:33 AM Guillaume Nodet  wrote:
> >
> > > Hi everyone,
> > >
> > > Last week, I worked on a fully immutable maven model. The results are
> > > available at [1].  The modifications required in modello were a bit too
> > > complicated, so I ended up using the modello models, but generating the
> > > models, readers and writers using velocity templates. The templates are
> > > actually way easier to modify than the modello generators, as you can
> see
> > > in the template generating the model [2] or the reader [3].  This also
> > > allows generating mergers and transformers.
> > > This also allows getting rid completely of plexus-utils dependency in
> the
> > > API.
> > >
> > > This all looks quite nice to me, however those changes are definitely
> > > incompatible, which means plugins will just break at runtime or compile
> > > time if they try to instantiate or modify objects from the model. If
> > > there's a consensus on trying to move forward with an immutable model,
> I
> > > can investigate generating this immutable model into a separate new
> > package
> > > and only use it for the new API, and rewrite the mutable model by
> > wrapping
> > > the immutable one. This would allow a smoother integration / migration.
> > >
> > > Feedback welcomed !
> > >
> > > Cheers,
> > > Guillaume Nodet
> > >
> > > [1] https://github.com/gnodet/maven/tree/m-api-immutable
> > > [2]
> > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-model/src/main/mdo/model.vm
> > > [3]
> > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> > >
> > > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet  a
> > écrit
> > > :
> > >
> > > > Hi everyone,
> > > >
> > > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> > Forward
> > > > to 3.5.4" thread, I'd like to start the discussion around it.
> > > >
> > > > Over the past weeks, I've worked on an experimental API for Maven
> 4.x.
> > > > The goals are multiple :
> > > >   * fix some problems with designs that do not work well with
> > > > multithreading
> > > >   * offer a way to finally get rid of deprecated code
> > > >   * offer a complete API (which would deprecate m-artifact-transfer,
> > > > m-dependency-tree)
> > > >   * offer an homogeneous and a bit more modern API
> > > >   * completely hide the maven-resolver, so that it can finally
> upgrade
> > to
> > > > a v2 with the package renamed without too much disturbance
> > > >
> > > > The goal would be to extract the models and API in a separate project
> > > with
> > > > a much lower release cycle, as those rarely change, but are currently
> > > > released with each version of maven.
> > > >
> > > > The current API can be seen at [1].  Note that the plugins API has
> also
> > > > been included within the new API and the plugin tools have been
> updated
> > > so
> > > 

Re: [DISCUSS] New Maven Core API for 4.x

[Mark Derricutt]

 We’re over at https://github.com/repaint-io/maven-tiles


What we’re doing is essential “evil” and mixing in “tiles” as implicit
parents.

It’s it’s no longer possible with 4.x - and if 4.x could provide something
similar, with a transition path we could document, I’m down with sunsetting
the project for 4.x+.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 29/03/2022 at 8:53:06 AM, Guillaume Nodet  wrote:

> Le lun. 28 mars 2022 à 21:22, Mark Derricutt  a écrit :
>
>  I wonder how much of this will break what we do with the
>
> tiles-maven-plugin, where we essentially “inject” parents into the model
>
> via a maven extension.
>
>
>
> Interesting. Do you have a pointer to that plugin's source code ?
>
> Guillaume
>
>

Re: [DISCUSS] New Maven Core API for 4.x

[Guillaume Nodet]

Le lun. 28 mars 2022 à 21:22, Mark Derricutt  a écrit :

>  I wonder how much of this will break what we do with the
> tiles-maven-plugin, where we essentially “inject” parents into the model
> via a maven extension.
>

Interesting. Do you have a pointer to that plugin's source code ?

Guillaume


>
> I remember I was seeing some odd issues under earlier builds of 4.x as well
> some time ago but will need to refresh my memory on what that was now.
> Something about properties no longer passing down to those injected parents
> if I recall.
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On 29/03/2022 at 6:30:24 AM, Guillaume Nodet  wrote:
>
> > What I have in mind is that plugins that use the new api would receive
> the
> > immutable model, while plugins that use the old (3.x) api would receive a
> > model that would wrap the immutable one. However, I think mutating the
> > model or the maven project should be done via services provided by the
> > maven api. That will allow controlling concurrent access, interception,
> > logging, etc...
> > For example, adding a source directory in the new api is done using the
> > ProjectManager, which I think should be the place where the project is
> > mutated:
> >
>


-- 

Guillaume Nodet

Re: [DISCUSS] New Maven Core API for 4.x

[Mark Derricutt]

 I wonder how much of this will break what we do with the
tiles-maven-plugin, where we essentially “inject” parents into the model
via a maven extension.

I remember I was seeing some odd issues under earlier builds of 4.x as well
some time ago but will need to refresh my memory on what that was now.
Something about properties no longer passing down to those injected parents
if I recall.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 29/03/2022 at 6:30:24 AM, Guillaume Nodet  wrote:

> What I have in mind is that plugins that use the new api would receive the
> immutable model, while plugins that use the old (3.x) api would receive a
> model that would wrap the immutable one. However, I think mutating the
> model or the maven project should be done via services provided by the
> maven api. That will allow controlling concurrent access, interception,
> logging, etc...
> For example, adding a source directory in the new api is done using the
> ProjectManager, which I think should be the place where the project is
> mutated:
>

Re: [DISCUSS] New Maven Core API for 4.x

[Guillaume Nodet]

What I have in mind is that plugins that use the new api would receive the
immutable model, while plugins that use the old (3.x) api would receive a
model that would wrap the immutable one. However, I think mutating the
model or the maven project should be done via services provided by the
maven api. That will allow controlling concurrent access, interception,
logging, etc...
For example, adding a source directory in the new api is done using the
ProjectManager, which I think should be the place where the project is
mutated:

https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectManager.java
I assume the number of plugins that mutate the project is small.  I think
the best way would be to provide atomic apis for mutating the parts that
need to be so that maven can have tighter control, but we can always
provide an api to replace the Project or the Model with a new copy if
needed so that any plugin can have the possibility to mutate those.
Does that make sense?

Guillaume

Le lun. 28 mars 2022 à 13:47, Matt Benson  a écrit :

> So in the new API, what kind of component would receive a mutable model if
> not a plugin? I.e., what would be the correct mechanism for enhancing the
> project model at runtime?
>
> Matt
>
> On Mon, Mar 28, 2022, 4:33 AM Guillaume Nodet  wrote:
>
> > Hi everyone,
> >
> > Last week, I worked on a fully immutable maven model. The results are
> > available at [1].  The modifications required in modello were a bit too
> > complicated, so I ended up using the modello models, but generating the
> > models, readers and writers using velocity templates. The templates are
> > actually way easier to modify than the modello generators, as you can see
> > in the template generating the model [2] or the reader [3].  This also
> > allows generating mergers and transformers.
> > This also allows getting rid completely of plexus-utils dependency in the
> > API.
> >
> > This all looks quite nice to me, however those changes are definitely
> > incompatible, which means plugins will just break at runtime or compile
> > time if they try to instantiate or modify objects from the model. If
> > there's a consensus on trying to move forward with an immutable model, I
> > can investigate generating this immutable model into a separate new
> package
> > and only use it for the new API, and rewrite the mutable model by
> wrapping
> > the immutable one. This would allow a smoother integration / migration.
> >
> > Feedback welcomed !
> >
> > Cheers,
> > Guillaume Nodet
> >
> > [1] https://github.com/gnodet/maven/tree/m-api-immutable
> > [2]
> >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-model/src/main/mdo/model.vm
> > [3]
> >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> >
> > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet  a
> écrit
> > :
> >
> > > Hi everyone,
> > >
> > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> Forward
> > > to 3.5.4" thread, I'd like to start the discussion around it.
> > >
> > > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > > The goals are multiple :
> > >   * fix some problems with designs that do not work well with
> > > multithreading
> > >   * offer a way to finally get rid of deprecated code
> > >   * offer a complete API (which would deprecate m-artifact-transfer,
> > > m-dependency-tree)
> > >   * offer an homogeneous and a bit more modern API
> > >   * completely hide the maven-resolver, so that it can finally upgrade
> to
> > > a v2 with the package renamed without too much disturbance
> > >
> > > The goal would be to extract the models and API in a separate project
> > with
> > > a much lower release cycle, as those rarely change, but are currently
> > > released with each version of maven.
> > >
> > > The current API can be seen at [1].  Note that the plugins API has also
> > > been included within the new API and the plugin tools have been updated
> > so
> > > that the maven-plugin-plugin supports both v3 api and the new v4 api.
> A
> > > new flag has been added to the MojoDescriptor to know if the plugin is
> > > using the old or the new api.  The plugin testing harness tools have
> been
> > > updated to junit 5 and now provide a few annotations [2] to help
> writing
> > > plugin tests [3].  The maven-core has been enhanced to support loading
> > > those new v4 plugins along with the v3 ones, which means they can work
> > > side-by-side in the same build.  This is done by implementing the new
> API
> > > by wrapping the v3 implementation classes (such as MavenSession,
> > > MavenProject, etc...) [4].
> > > I've ported a few plugins such as clean [5], install [6], deploy [7]
> as a
> > > proof-of-concept that this actually works.
> > >
> > > The very rough goal would be to to have multiple phases:
> > >   * continue the work on this API so that it can actually cover all use

Re: [VOTE] - Release Apache Maven Shade Plugin Version 3.3.0

[Karl Heinz Marbaise]

Hi,

can I get some more PMC VOTE's because there are not enough PMC votes yet...


formally I need one more PMC Vote...


Kind regards
Karl Heinz Marbaise

On 24.03.22 19:21, Karl Heinz Marbaise wrote:

Hi,

We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12348391=Text


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC


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

https://repository.apache.org/service/local/repositories/maven-1730/content/org/apache/maven/plugins/maven-shade-plugin/3.3.0/maven-shade-plugin-3.3.0-source-release.zip


Source release checksum(s):
maven-shade-plugin-3.3.0-source-release.zip sha512:
f88196508ca14442c7b6e6cf8e09b9e6d5ad7139e5c95d27b4f0ae390c4339277248ded7ddef5fd43151b9bc6abaaab6157d478fe4a73f941004cb8429bbfefd


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

Kind regards
Karl Heinz Marbaise

-
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 Shade Plugin Version 3.3.0

[Karl Heinz Marbaise]

+1
from me.

kind regards
Karl Heinz Marbaise
On 24.03.22 19:21, Karl Heinz Marbaise wrote:

Hi,

We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12348391=Text


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC


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

https://repository.apache.org/service/local/repositories/maven-1730/content/org/apache/maven/plugins/maven-shade-plugin/3.3.0/maven-shade-plugin-3.3.0-source-release.zip


Source release checksum(s):
maven-shade-plugin-3.3.0-source-release.zip sha512:
f88196508ca14442c7b6e6cf8e09b9e6d5ad7139e5c95d27b4f0ae390c4339277248ded7ddef5fd43151b9bc6abaaab6157d478fe4a73f941004cb8429bbfefd


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

Kind regards
Karl Heinz Marbaise

-
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 18 General Availability, and oracle-actions/setup-java

[David Delabassee]

Greetings!

JDK 18 has been released (General Availability) on March 22nd as 
planned, the release cadence is working like clockwork! As a small token 
of gratitude, some of you have been specifically acknowledged in the 
"The Arrival of Java 18" announcement [1]. On behalf of the entire team, 
let me extend our thanks to all of you.


With JDK 18 released, the focus should now be on making sure your 
project(s) compile and work on JDK 19. As always, if you face any issue 
with early-access builds of JDK 19 please let us know. To help you in 
this task, we have just released a GitHub action to install the OpenJDK 
Early-Access builds. For more information, please check the heads-up below.


I'll conclude with a short teaser, i.e. JavaOne is Back! [2] Stay tuned 
for more details.


[1] https://inside.java/2022/03/22/the-arrival-of-java18/
[2] https://www.oracle.com/cloudworld/javaone/


## Heads-Up: oracle-actions/setup-java

To help you test your project(s), we have released a GitHub Action [3] 
to download and install various JDK builds produced by Oracle. In 
addition to the latest OpenJDK GA builds (GPL v2 W/CPE) and the Oracle 
JDK builds (NFTC license), this action can also download and install 
OpenJDK early-access builds, and early-access builds of OpenJDK projects 
(ex. Project Loom, Project Valhalla, etc.).


When doing tests using EA builds, it is key to always use the upstream 
EA builds from jdk.java.net as issues should be logged against those 
upstream builds, and ideally against a specific build version. This 
GitHub action is actively following the OpenJDK EA builds releases. 
Please make sure to check the announcement [4] for more details, and 
short FAQ.


To help you isolate regression between different EA builds, we are 
working to add support for archived builds. If you have feedback, please 
either issue the Issue tracker [5] or just send me a mail.


[3] 
https://github.com/marketplace/actions/setup-java-development-kits-built-by-oracle

[4] https://inside.java/2022/03/11/setup-java/
[5] https://github.com/oracle-actions/setup-java/issues


## General Availability of Java 18 / JDK 18

JDK 18 is now Generally Available [6]. The OpenJDK builds which are 
provided under the GNU General Public License v2, with the Classpath 
Exception are available [7], the JDK 18 Release Notes are also available 
[8].


[6] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-March/006458.html
[7] https://jdk.java.net/18/
[8] https://jdk.java.net/18/release-notes

Along with hundreds of smaller enhancements and over a thousand bug 
fixes, JDK 18 includes following JEPs:

- JEP 400: UTF-8 by Default
- JEP 408: Simple Web Server
- JEP 413: Code Snippets in Java API Documentation
- JEP 416: Reimplement Core Reflection with Method Handles
- JEP 417: Vector API (Third Incubator)
- JEP 418: Internet-Address Resolution SPI
- JEP 419: Foreign Function & Memory API (Second Incubator)
- JEP 420: Pattern Matching for switch (Second Preview)
- JEP 421: Deprecate Finalization for Removal

Thanks to everyone who contributed to JDK 18, whether by designing and 
implementing features or enhancements, by fixing bugs, or by downloading 
and testing the early-access builds.



## JDK 19 Early-Access builds

JDK 19 Early-Access builds 15 are now available [9], and are provided 
under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are also available [10].


[9] https://jdk.java.net/19/
[10] https://jdk.java.net/19/release-notes

### JEPs targeted to JDK 19, so far:
- JEP 422: Linux/RISC-V Port https://openjdk.java.net/jeps/422

### Recent changes that maybe of interest:
- JDK-8283415: Update java.lang.ref to use sealed classes
- JDK-8280494: (D)TLS signature schemes
- JDK-8282081: java.time.DateTimeFormatter: wrong definition of symbol F
- JDK-8281181: Do not use CPU Shares to compute active processor count
- JDK-7192189: Support endpoint identification algorithm in RFC 6125
- JDK-8277474: jarsigner does not check if algorithm parameters are disabled
- JDK-8280357: If the users home directory is invalid, system property 
user.home is set to $HOME

- JDK-8277204: Implement PAC-RET branch protection on Linux/AArch64
- JDK-8282411: Add useful predicates to ElementKind
- JDK-8282131: java.time.ZoneId should be a sealed abstract class
- JDK-8281375: Accelerate bitCount operation for AVX2 and AVX512 target


## Topics of Interest:

- “Java 18 is Here!” - Inside Java Podcast
https://inside.java/2022/03/22/podcast-023/

- “The Simple Web Server” - Inside Java Podcast
https://inside.java/2022/03/04/podcast-022/

- “Finalization Deprecation” - Inside Java Podcast
https://inside.java/2022/01/12/podcast-021/

- All About JDK 18 - Inside Java Newscast
https://inside.java/2022/03/10/insidejava-newscast-021/

- JDK 18 - Security Enhancements
https://seanjmullan.org/blog/2022/03/23/jdk18

- JDK 18 - Programmer's Guide to Snippets
https://docs.oracle.com/en/java/javase/18/code-snippet/index.html

- 

Re: [DISCUSS] New Maven Core API for 4.x

[Matt Benson]

So in the new API, what kind of component would receive a mutable model if
not a plugin? I.e., what would be the correct mechanism for enhancing the
project model at runtime?

Matt

On Mon, Mar 28, 2022, 4:33 AM Guillaume Nodet  wrote:

> Hi everyone,
>
> Last week, I worked on a fully immutable maven model. The results are
> available at [1].  The modifications required in modello were a bit too
> complicated, so I ended up using the modello models, but generating the
> models, readers and writers using velocity templates. The templates are
> actually way easier to modify than the modello generators, as you can see
> in the template generating the model [2] or the reader [3].  This also
> allows generating mergers and transformers.
> This also allows getting rid completely of plexus-utils dependency in the
> API.
>
> This all looks quite nice to me, however those changes are definitely
> incompatible, which means plugins will just break at runtime or compile
> time if they try to instantiate or modify objects from the model. If
> there's a consensus on trying to move forward with an immutable model, I
> can investigate generating this immutable model into a separate new package
> and only use it for the new API, and rewrite the mutable model by wrapping
> the immutable one. This would allow a smoother integration / migration.
>
> Feedback welcomed !
>
> Cheers,
> Guillaume Nodet
>
> [1] https://github.com/gnodet/maven/tree/m-api-immutable
> [2]
>
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-model/src/main/mdo/model.vm
> [3]
>
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
>
> Le lun. 14 mars 2022 à 08:59, Guillaume Nodet  a écrit
> :
>
> > Hi everyone,
> >
> > As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
> > to 3.5.4" thread, I'd like to start the discussion around it.
> >
> > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > The goals are multiple :
> >   * fix some problems with designs that do not work well with
> > multithreading
> >   * offer a way to finally get rid of deprecated code
> >   * offer a complete API (which would deprecate m-artifact-transfer,
> > m-dependency-tree)
> >   * offer an homogeneous and a bit more modern API
> >   * completely hide the maven-resolver, so that it can finally upgrade to
> > a v2 with the package renamed without too much disturbance
> >
> > The goal would be to extract the models and API in a separate project
> with
> > a much lower release cycle, as those rarely change, but are currently
> > released with each version of maven.
> >
> > The current API can be seen at [1].  Note that the plugins API has also
> > been included within the new API and the plugin tools have been updated
> so
> > that the maven-plugin-plugin supports both v3 api and the new v4 api.  A
> > new flag has been added to the MojoDescriptor to know if the plugin is
> > using the old or the new api.  The plugin testing harness tools have been
> > updated to junit 5 and now provide a few annotations [2] to help writing
> > plugin tests [3].  The maven-core has been enhanced to support loading
> > those new v4 plugins along with the v3 ones, which means they can work
> > side-by-side in the same build.  This is done by implementing the new API
> > by wrapping the v3 implementation classes (such as MavenSession,
> > MavenProject, etc...) [4].
> > I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> > proof-of-concept that this actually works.
> >
> > The very rough goal would be to to have multiple phases:
> >   * continue the work on this API so that it can actually cover all use
> > cases for plugins, create a new project with the new API and models, make
> > sure plugins can work correctly with the new API / implementation
> >   * release the API, then maven-core supporting the new API
> >   * upgrade plugins to the new API, deprecate old components and API
> >   * once all plugins have migrated to the new API, switch maven-core
> > implementation to the new API
> >
> > I'm eager to hear your thoughts !
> >
> > [1]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > [2]
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > [3]
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > [4]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> >
> > --
> > 
> > Guillaume Nodet
> >
> >
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] New Maven Core API for 4.x

[Romain Manni-Bucau]

+1 to move that way but also +1 to keep plugins working (I don't see all
plugins of the ecosystem being rewritten within 5 years so a light plugin
compat layer would be neat).

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



Le lun. 28 mars 2022 à 11:33, Guillaume Nodet  a écrit :

> Hi everyone,
>
> Last week, I worked on a fully immutable maven model. The results are
> available at [1].  The modifications required in modello were a bit too
> complicated, so I ended up using the modello models, but generating the
> models, readers and writers using velocity templates. The templates are
> actually way easier to modify than the modello generators, as you can see
> in the template generating the model [2] or the reader [3].  This also
> allows generating mergers and transformers.
> This also allows getting rid completely of plexus-utils dependency in the
> API.
>
> This all looks quite nice to me, however those changes are definitely
> incompatible, which means plugins will just break at runtime or compile
> time if they try to instantiate or modify objects from the model. If
> there's a consensus on trying to move forward with an immutable model, I
> can investigate generating this immutable model into a separate new package
> and only use it for the new API, and rewrite the mutable model by wrapping
> the immutable one. This would allow a smoother integration / migration.
>
> Feedback welcomed !
>
> Cheers,
> Guillaume Nodet
>
> [1] https://github.com/gnodet/maven/tree/m-api-immutable
> [2]
>
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-model/src/main/mdo/model.vm
> [3]
>
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
>
> Le lun. 14 mars 2022 à 08:59, Guillaume Nodet  a écrit
> :
>
> > Hi everyone,
> >
> > As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
> > to 3.5.4" thread, I'd like to start the discussion around it.
> >
> > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > The goals are multiple :
> >   * fix some problems with designs that do not work well with
> > multithreading
> >   * offer a way to finally get rid of deprecated code
> >   * offer a complete API (which would deprecate m-artifact-transfer,
> > m-dependency-tree)
> >   * offer an homogeneous and a bit more modern API
> >   * completely hide the maven-resolver, so that it can finally upgrade to
> > a v2 with the package renamed without too much disturbance
> >
> > The goal would be to extract the models and API in a separate project
> with
> > a much lower release cycle, as those rarely change, but are currently
> > released with each version of maven.
> >
> > The current API can be seen at [1].  Note that the plugins API has also
> > been included within the new API and the plugin tools have been updated
> so
> > that the maven-plugin-plugin supports both v3 api and the new v4 api.  A
> > new flag has been added to the MojoDescriptor to know if the plugin is
> > using the old or the new api.  The plugin testing harness tools have been
> > updated to junit 5 and now provide a few annotations [2] to help writing
> > plugin tests [3].  The maven-core has been enhanced to support loading
> > those new v4 plugins along with the v3 ones, which means they can work
> > side-by-side in the same build.  This is done by implementing the new API
> > by wrapping the v3 implementation classes (such as MavenSession,
> > MavenProject, etc...) [4].
> > I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> > proof-of-concept that this actually works.
> >
> > The very rough goal would be to to have multiple phases:
> >   * continue the work on this API so that it can actually cover all use
> > cases for plugins, create a new project with the new API and models, make
> > sure plugins can work correctly with the new API / implementation
> >   * release the API, then maven-core supporting the new API
> >   * upgrade plugins to the new API, deprecate old components and API
> >   * once all plugins have migrated to the new API, switch maven-core
> > implementation to the new API
> >
> > I'm eager to hear your thoughts !
> >
> > [1]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > [2]
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > [3]
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > [4]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > [5] 

Re: [DISCUSS] New Maven Core API for 4.x

[Guillaume Nodet]

Hi everyone,

Last week, I worked on a fully immutable maven model. The results are
available at [1].  The modifications required in modello were a bit too
complicated, so I ended up using the modello models, but generating the
models, readers and writers using velocity templates. The templates are
actually way easier to modify than the modello generators, as you can see
in the template generating the model [2] or the reader [3].  This also
allows generating mergers and transformers.
This also allows getting rid completely of plexus-utils dependency in the
API.

This all looks quite nice to me, however those changes are definitely
incompatible, which means plugins will just break at runtime or compile
time if they try to instantiate or modify objects from the model. If
there's a consensus on trying to move forward with an immutable model, I
can investigate generating this immutable model into a separate new package
and only use it for the new API, and rewrite the mutable model by wrapping
the immutable one. This would allow a smoother integration / migration.

Feedback welcomed !

Cheers,
Guillaume Nodet

[1] https://github.com/gnodet/maven/tree/m-api-immutable
[2]
https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-model/src/main/mdo/model.vm
[3]
https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm

Le lun. 14 mars 2022 à 08:59, Guillaume Nodet  a écrit :

> Hi everyone,
>
> As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
> to 3.5.4" thread, I'd like to start the discussion around it.
>
> Over the past weeks, I've worked on an experimental API for Maven 4.x.
> The goals are multiple :
>   * fix some problems with designs that do not work well with
> multithreading
>   * offer a way to finally get rid of deprecated code
>   * offer a complete API (which would deprecate m-artifact-transfer,
> m-dependency-tree)
>   * offer an homogeneous and a bit more modern API
>   * completely hide the maven-resolver, so that it can finally upgrade to
> a v2 with the package renamed without too much disturbance
>
> The goal would be to extract the models and API in a separate project with
> a much lower release cycle, as those rarely change, but are currently
> released with each version of maven.
>
> The current API can be seen at [1].  Note that the plugins API has also
> been included within the new API and the plugin tools have been updated so
> that the maven-plugin-plugin supports both v3 api and the new v4 api.  A
> new flag has been added to the MojoDescriptor to know if the plugin is
> using the old or the new api.  The plugin testing harness tools have been
> updated to junit 5 and now provide a few annotations [2] to help writing
> plugin tests [3].  The maven-core has been enhanced to support loading
> those new v4 plugins along with the v3 ones, which means they can work
> side-by-side in the same build.  This is done by implementing the new API
> by wrapping the v3 implementation classes (such as MavenSession,
> MavenProject, etc...) [4].
> I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> proof-of-concept that this actually works.
>
> The very rough goal would be to to have multiple phases:
>   * continue the work on this API so that it can actually cover all use
> cases for plugins, create a new project with the new API and models, make
> sure plugins can work correctly with the new API / implementation
>   * release the API, then maven-core supporting the new API
>   * upgrade plugins to the new API, deprecate old components and API
>   * once all plugins have migrated to the new API, switch maven-core
> implementation to the new API
>
> I'm eager to hear your thoughts !
>
> [1]
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> [2]
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> [3]
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> [4]
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
>
> --
> 
> Guillaume Nodet
>
>

-- 

Guillaume Nodet

Surprises on maven 4

[Romain Manni-Bucau]

Hi all,

For an output check (thanks again Michael for the pointer), I tested maven
master/4 this morning and get a few question marks:

1. I know we warn when a plugin has no lock version but it also means we
implicitly force to define a plugin and warn we defined it, this does not
make much sense from an user point of view for me so either we should keep
a default version aligned on maven version or just not enforce any plugin
if not defined in the pom (means if I did not define install plugin, mvn
install wouldn't install - don't think it is good but it is not worse than
warning for an implicit definition when something implicit had been done
IMHO)
2. I was not able to reproduce it after an install but I got at first build
this error (mvn clean install -DskipTests -T8):

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project : Execution default-install of goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
Unable to provision, see the following errors:
[ERROR]
[ERROR] 1) Error in custom provider, java.lang.IllegalStateException
[ERROR]   at ClassRealm[plexus.core, parent: null] (via modules:
org.eclipse.sisu.wire.WireModule ->
org.eclipse.sisu.plexus.PlexusBindingModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
[ERROR]   while locating org.apache.maven.execution.MavenSession
[ERROR]
[ERROR] 1 error
[ERROR] -> [Help 1]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project orchestrator: Execution default-install of
goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
Unable to provision, see the following errors:
[ERROR]
[ERROR] 1) Error in custom provider, java.lang.IllegalStateException
[ERROR]   at ClassRealm[plexus.core, parent: null] (via modules:
org.eclipse.sisu.wire.WireModule ->
org.eclipse.sisu.plexus.PlexusBindingModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
[ERROR]   while locating org.apache.maven.execution.MavenSession
[ERROR]
[ERROR] 1 error

I'm a bit suspicious about this last one since there is a new resolution of
project modules, anyone with some idea?

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