Re: extracting XML classes from plexus-utils to plexus-xml

2022-12-30 Thread Romain Manni-Bucau 
+1 and maybe drop the builder from plexus package for v4 (not too late to
fix it)

Le ven. 30 déc. 2022 à 23:56, Hervé Boutemy  a
écrit :

> ok, if everyone wants to go that route of clarifying dependency from Maven
> on
> plexus-utils, let's go and do it fully.
>
> First, I'm lost if you call "plexus-xml" an artifact that is maintained at
> Maven. So we'll need to rephrase with one strict convention: plexus-*
> artifacts are maintained at Plexus, maven-* are maintained at Maven.
>
>
> Then let's define where the strong dependency is:
> correct me if I'm wrong, Maven core provides 5 classes from plexus-utils
> 3.x
> to the whole plugins/extensions ecosystem [1]:
> 1. org.codehaus.plexus.util.xml.Xpp3Dom
> 2. org.codehaus.plexus.util.xml.Xpp3DomBuilder
> 3. org.codehaus.plexus.util.xml.pull.XmlPullParser
> 4. org.codehaus.plexus.util.xml.pull.XmlPullParserException
> 5. org.codehaus.plexus.util.xml.pull.XmlSerializer
> (it was only 4 classes in Maven 3, but Xpp3DomBuilder was added in Maven 4)
>
> then for compatibility reason these 5 classes can't have their public API
> changed = it is the only place where there is a strong dependency from
> whole
> Maven to Plexus Utils
> Because if any plugin uses an implementation at build time (old version,
> for
> example), at runtime, Maven core injects the Maven core provided classes.
>
>
> For everything else that is available in Plexus Utils, we have
> maven-shared-
> utils that was created years ago and that was globally ignored [2].
> If people want to migrate, they just can for years, independently in each
> plugin or even in Maven core.
>
>
> If we want to have a clean state, we can implement these 5 classes in the
> current maven-xml-impl, that I propose to name maven-plexus-utils-xml, or
> shorter maven-plexus-xml.
> As the artifact name tells, it is maintained at Maven level. And "of
> course",
> it MUST NOT depend on Plexus Utils given the intent of getting out of that
> dependency...
> It is expected to be very stable, because it is a key compatibility
> contract
> between Maven core and the whole plugins/extensions ecosystem:
> could/should be
> extracted from Maven core releases, moved to shared/ components.
>
>
> At Plexus Utils level, I propose that we (the Plexus org) do a version 4
> that
> removes the 5 classes, replacing with a dependency on maven-plexus-xml
> that
> was written in Maven.
> Then when Maven core migrates to plexus-utils 4, it remove the current
> need to
> have inside Maven core a local shaded "plexus-utils" (that should have
> been
> named maven-plexus-utils for clarity) [3]
>
>
> Is that plan clear and accurate?
>
> Regards,
>
> Hervé
>
>
> [1]
> https://github.com/apache/maven/blob/master/maven-core/src/main/resources/
> META-INF/maven/extension.xml#L85
> 
>
> [2] https://maven.apache.org/shared/maven-shared-utils/
>
> [3] https://github.com/apache/maven/tree/master/plexus-utils
>
> Le vendredi 30 décembre 2022, 16:44:49 CET Guillaume Nodet a écrit :
> > To reduce dependency from maven to plexus, we could keep the xml api and
> > implementation which are used by maven 4 inside maven, and update
> > plexus-utils (or the new plexus-xml) to be compatible with the new
> > immutable DOM api from maven.
> >
> > So this would mean:
> >   * move the two re-implemented plexus classes from maven to a new
> > plexus-xml project:
> >
> https://github.com/apache/maven/tree/master/maven-xml-impl/src/main/java/org
> > /codehaus/plexus/util/xml
> >
> >   * plexus-xml would depend on maven-api-xml and maven-xml-impl (or
> > whatever it will be renamed)
> >   * modify plexus-utils to depend on plexus-xml
> > One plexus-xml and plexus-utils are released, this would allow to remove
> > from maven:
> >   * the two xml classes
> >   * the repackaged plexus-utils
> >
> > Le ven. 30 déc. 2022 à 16:21, Benjamin Marwell  a
> >
> > écrit :
> > > +1 to what Romain said. Let's reduce dependencies to other orgs where
> > > possible and feasible. It is, in this case.
> > >
> > >
> > >
> > >
> > > On Fri, 30 Dec 2022, 10:27 Romain Manni-Bucau, 
> > >
> > > wrote:
> > > > Hi Hervé,
> > > >
> > > > As mentionned in the thread I think it makes sense to freeze plexus
> and
> > > > slowly import to maven the related code so I'd be to import the
> parts we
> > > > need (guess some abstraction can be dropped at the same time).
> > > > So +1 to split, -0 to do it at plexus, +1 to do it in maven.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > >
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > > e
> > >
> > > > Le ven. 30 déc. 2022 à 10:22, Hervé

Re: extracting XML classes from plexus-utils to plexus-xml

2022-12-30 Thread Hervé Boutemy 
ok, if everyone wants to go that route of clarifying dependency from Maven on 
plexus-utils, let's go and do it fully.

First, I'm lost if you call "plexus-xml" an artifact that is maintained at 
Maven. So we'll need to rephrase with one strict convention: plexus-* 
artifacts are maintained at Plexus, maven-* are maintained at Maven.


Then let's define where the strong dependency is:
correct me if I'm wrong, Maven core provides 5 classes from plexus-utils 3.x 
to the whole plugins/extensions ecosystem [1]:
1. org.codehaus.plexus.util.xml.Xpp3Dom
2. org.codehaus.plexus.util.xml.Xpp3DomBuilder
3. org.codehaus.plexus.util.xml.pull.XmlPullParser
4. org.codehaus.plexus.util.xml.pull.XmlPullParserException
5. org.codehaus.plexus.util.xml.pull.XmlSerializer
(it was only 4 classes in Maven 3, but Xpp3DomBuilder was added in Maven 4)

then for compatibility reason these 5 classes can't have their public API 
changed = it is the only place where there is a strong dependency from whole 
Maven to Plexus Utils
Because if any plugin uses an implementation at build time (old version, for 
example), at runtime, Maven core injects the Maven core provided classes.


For everything else that is available in Plexus Utils, we have maven-shared-
utils that was created years ago and that was globally ignored [2]. 
If people want to migrate, they just can for years, independently in each 
plugin or even in Maven core.


If we want to have a clean state, we can implement these 5 classes in the 
current maven-xml-impl, that I propose to name maven-plexus-utils-xml, or 
shorter maven-plexus-xml.
As the artifact name tells, it is maintained at Maven level. And "of course", 
it MUST NOT depend on Plexus Utils given the intent of getting out of that 
dependency...
It is expected to be very stable, because it is a key compatibility contract 
between Maven core and the whole plugins/extensions ecosystem: could/should be 
extracted from Maven core releases, moved to shared/ components.


At Plexus Utils level, I propose that we (the Plexus org) do a version 4 that 
removes the 5 classes, replacing with a dependency on maven-plexus-xml that 
was written in Maven.
Then when Maven core migrates to plexus-utils 4, it remove the current need to 
have inside Maven core a local shaded "plexus-utils" (that should have been 
named maven-plexus-utils for clarity) [3]


Is that plan clear and accurate?

Regards,

Hervé


[1] https://github.com/apache/maven/blob/master/maven-core/src/main/resources/
META-INF/maven/extension.xml#L85

[2] https://maven.apache.org/shared/maven-shared-utils/

[3] https://github.com/apache/maven/tree/master/plexus-utils

Le vendredi 30 décembre 2022, 16:44:49 CET Guillaume Nodet a écrit :
> To reduce dependency from maven to plexus, we could keep the xml api and
> implementation which are used by maven 4 inside maven, and update
> plexus-utils (or the new plexus-xml) to be compatible with the new
> immutable DOM api from maven.
> 
> So this would mean:
>   * move the two re-implemented plexus classes from maven to a new
> plexus-xml project:
> https://github.com/apache/maven/tree/master/maven-xml-impl/src/main/java/org
> /codehaus/plexus/util/xml
> 
>   * plexus-xml would depend on maven-api-xml and maven-xml-impl (or
> whatever it will be renamed)
>   * modify plexus-utils to depend on plexus-xml
> One plexus-xml and plexus-utils are released, this would allow to remove
> from maven:
>   * the two xml classes
>   * the repackaged plexus-utils
> 
> Le ven. 30 déc. 2022 à 16:21, Benjamin Marwell  a
> 
> écrit :
> > +1 to what Romain said. Let's reduce dependencies to other orgs where
> > possible and feasible. It is, in this case.
> > 
> > 
> > 
> > 
> > On Fri, 30 Dec 2022, 10:27 Romain Manni-Bucau, 
> > 
> > wrote:
> > > Hi Hervé,
> > > 
> > > As mentionned in the thread I think it makes sense to freeze plexus and
> > > slowly import to maven the related code so I'd be to import the parts we
> > > need (guess some abstraction can be dropped at the same time).
> > > So +1 to split, -0 to do it at plexus, +1 to do it in maven.
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > 
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e
> > 
> > > Le ven. 30 déc. 2022 à 10:22, Hervé Boutemy  a
> > > 
> > > écrit :
> > > > while working on the XML side of Maven 4 immutable API, we had the
> > > > idea
> > > 
> > > of
> > > 
> > > > extracting the XML code from plexus-utils to a new separate plexus-xml
> > > > artifact
> > > > that could be done for version 4
> > > > 
> > > > see https://github.com/codehaus-plexus/plexus-utils/issues/228
> > > > 
> > > > any  objection?
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > 
> >

[ANN] Apache Maven 3.8.7 released

2022-12-30 Thread Michael Osipov 
The Apache Maven team is pleased to announce the release of the Apache 
Maven 3.8.7


Apache Maven is a software project management and comprehension tool. 
Based on the concept
of a project object model (POM), Maven can manage a project's build, 
reporting and documentation

from a central piece of information.

Maven 3.8.7 is available via https://maven.apache.org/download.cgi

The core release is independent of plugin releases. Further releases of 
plugins will be made

separately.

If you have any questions, please consult:

- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the reference documentation: https://maven.apache.org/ref/3.8.7/


Release Notes - Maven - Version 3.8.7

** Sub-task
* [MNG-7019] - Notify also at start when profile is missing

** Bug
* [MNG-7106] - VersionRange.toString() produces a string that 
cannot be parsed with VersionRange.createFromVersionSpec() for same 
lower and upper bounds
* [MNG-7316] - REGRESSION: MavenProject.getAttachedArtifacts() is 
read-only
* [MNG-7352] - org.apache.maven.toolchain.java.JavaToolchainImpl 
should be public
* [MNG-7529] - Maven resolver makes bad repository choices when 
resolving version ranges
* [MNG-7563] - REGRESSION: User properties now override model 
properties in dependencies
* [MNG-7568] - [WARNING] The requested profile "ABCDEF" could not 
be activated because it does not exist.
* [MNG-7578] - Building Linux image on Windows impossible (patch 
incuded)

* [MNG-7600] - LocalRepositoryManager is created too early
* [MNG-7621] - Parameter '-f' causes ignoring any 'maven.config' 
(only on Windows)

* [MNG-7637] - Possible NPE in MavenProject#hashCode()
* [MNG-7644] - Fix version comparison where .X1 < -X2 for any 
string qualifier X


** Improvement
* [MNG-7590] - Allow configure resolver by properties in settings.xml
* [MNG-7645] - Implement some #toString() methods

** Task
* [MNG-7513] - Address commons-io_commons-io vulnerability found in 
maven latest version

* [MNG-7634] - Revert MNG-5982 and MNG-7417
* [MNG-7636] - Partially revert MNG-5868 to restore backward 
compatibility (see MNG-7316)


** Dependency upgrade
* [MNG-7506] - Upgrade Maven Wagon to 3.5.2
* [MNG-7641] - Upgrade Maven Wagon to 3.5.3


For more information read 
https://maven.apache.org/docs/3.8.7/release-notes.html


Enjoy!

- The Maven Team

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

[RESULT] [VOTE] Release Apache Maven version 3.8.7

2022-12-30 Thread Michael Osipov 

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Slawomir Jaranowski, Hervé Boutemy, Romain 
Manni-Bucau, Karl Heinz Marbaise, Tamás Cservenák, Arnaud Héritier, 
Olivier Lamy, Sylwester Lachiewicz, Mark Derricutt, Petr Široký


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: extracting XML classes from plexus-utils to plexus-xml

2022-12-30 Thread Guillaume Nodet 
To reduce dependency from maven to plexus, we could keep the xml api and
implementation which are used by maven 4 inside maven, and update
plexus-utils (or the new plexus-xml) to be compatible with the new
immutable DOM api from maven.

So this would mean:
  * move the two re-implemented plexus classes from maven to a new
plexus-xml project:
https://github.com/apache/maven/tree/master/maven-xml-impl/src/main/java/org/codehaus/plexus/util/xml

  * plexus-xml would depend on maven-api-xml and maven-xml-impl (or
whatever it will be renamed)
  * modify plexus-utils to depend on plexus-xml
One plexus-xml and plexus-utils are released, this would allow to remove
from maven:
  * the two xml classes
  * the repackaged plexus-utils

Le ven. 30 déc. 2022 à 16:21, Benjamin Marwell  a
écrit :

> +1 to what Romain said. Let's reduce dependencies to other orgs where
> possible and feasible. It is, in this case.
>
>
>
>
> On Fri, 30 Dec 2022, 10:27 Romain Manni-Bucau, 
> wrote:
>
> > Hi Hervé,
> >
> > As mentionned in the thread I think it makes sense to freeze plexus and
> > slowly import to maven the related code so I'd be to import the parts we
> > need (guess some abstraction can be dropped at the same time).
> > So +1 to split, -0 to do it at plexus, +1 to do it in maven.
> >
> > 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. 30 déc. 2022 à 10:22, Hervé Boutemy  a
> > écrit :
> >
> > > while working on the XML side of Maven 4 immutable API, we had the idea
> > of
> > > extracting the XML code from plexus-utils to a new separate plexus-xml
> > > artifact
> > > that could be done for version 4
> > >
> > > see https://github.com/codehaus-plexus/plexus-utils/issues/228
> > >
> > > any  objection?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>


-- 

Guillaume Nodet

Re: extracting XML classes from plexus-utils to plexus-xml

2022-12-30 Thread Benjamin Marwell 
+1 to what Romain said. Let's reduce dependencies to other orgs where
possible and feasible. It is, in this case.




On Fri, 30 Dec 2022, 10:27 Romain Manni-Bucau, 
wrote:

> Hi Hervé,
>
> As mentionned in the thread I think it makes sense to freeze plexus and
> slowly import to maven the related code so I'd be to import the parts we
> need (guess some abstraction can be dropped at the same time).
> So +1 to split, -0 to do it at plexus, +1 to do it in maven.
>
> 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. 30 déc. 2022 à 10:22, Hervé Boutemy  a
> écrit :
>
> > while working on the XML side of Maven 4 immutable API, we had the idea
> of
> > extracting the XML code from plexus-utils to a new separate plexus-xml
> > artifact
> > that could be done for version 4
> >
> > see https://github.com/codehaus-plexus/plexus-utils/issues/228
> >
> > any  objection?
> >
> > Regards,
> >
> > Hervé
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: extracting XML classes from plexus-utils to plexus-xml

2022-12-30 Thread Romain Manni-Bucau 
Hi Hervé,

As mentionned in the thread I think it makes sense to freeze plexus and
slowly import to maven the related code so I'd be to import the parts we
need (guess some abstraction can be dropped at the same time).
So +1 to split, -0 to do it at plexus, +1 to do it in maven.

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



Le ven. 30 déc. 2022 à 10:22, Hervé Boutemy  a
écrit :

> while working on the XML side of Maven 4 immutable API, we had the idea of
> extracting the XML code from plexus-utils to a new separate plexus-xml
> artifact
> that could be done for version 4
>
> see https://github.com/codehaus-plexus/plexus-utils/issues/228
>
> any  objection?
>
> Regards,
>
> Hervé
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

extracting XML classes from plexus-utils to plexus-xml

2022-12-30 Thread Hervé Boutemy 
while working on the XML side of Maven 4 immutable API, we had the idea of 
extracting the XML code from plexus-utils to a new separate plexus-xml 
artifact
that could be done for version 4

see https://github.com/codehaus-plexus/plexus-utils/issues/228

any  objection?

Regards,

Hervé



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