I've created a draft PR to switch the underlying plexus xml classes (the
Xpp3Dom and Xpp3DomBuilder) to wrap the maven provided implementation.
I need to investigate why 2 tests are failing though...
https://github.com/codehaus-plexus/plexus-utils/pull/236
Le mer. 1 févr. 2023 à 08:57, Herve Bou
> The only "problem" is that it
> creates a cycle between maven-core and plexus-utils, but
to reduce the problem, that's why I proposed at plexus-utils level to split the
xml part in another plexus-xml artifact, so at least the overlap is reduced and
there is clarification about the fact tha
On Tue, Jan 31, 2023 at 9:43 AM Guillaume Nodet wrote:
>
> So I think my earlier proposal is fine, i.e. remove the plexus classes from
> the maven code tree, update them where they belong (i.e. in the plexus
> code tree) by adding a dependency to the maven-xml-impl.
> This keeps org.apache.maven.*
Le mar. 31 janv. 2023 à 15:27, Elliotte Rusty Harold a
écrit :
> Very roughly my suggestion is create new artifacts that do what you
> want with completely new packages. Class names can stay the same but
> package names must change when the artifact ID or group ID changes.
>
> If you want to keep
Very roughly my suggestion is create new artifacts that do what you
want with completely new packages. Class names can stay the same but
package names must change when the artifact ID or group ID changes.
If you want to keep the fully package qualified class names the same,
then don't change the a
Maybe I'm wrong, but I think you missed the point.
We have new packages / new artifacts, mainly the xml api located in
the maven-api-xml artifact [1] with a single interface XmlNode [2].
The implementation is in the maven-xml-impl [3] artifact.
As I said, I'd like to keep it where it is.
Now, in
Thanks for the PR. That makes this clearer. I'm now -1 (-10?) on this
entire proposal. Renaming artifact IDs without renaming packages is a
recipe for hard to debug, hard to fix problems.
See https://jlbp.dev/JLBP-6 for detailed explanation and suggestions
To proceed what's needed is a hard fork
Le mar. 31 janv. 2023 à 01:31, Hervé Boutemy a
écrit :
> Le lundi 30 janvier 2023, 14:06:28 CET Guillaume Nodet a écrit :
> > Given this is
> >
> > Le lun. 30 janv. 2023 à 07:53, Hervé Boutemy a
> >
> > écrit :
> > > I think that first steps are:
> > >
> > > 1. release maven-api-meta as a shared
there is no problem with maven-api-meta(annotations) and maven-api-xml which
are completely new (java packages and artifactIds) and created for Maven core.
I added links to the documentation to share where everything lives and what it
contains
https://maven.apache.org/ref/4.0.0-alpha-4/api/index
Le lundi 30 janvier 2023, 14:06:28 CET Guillaume Nodet a écrit :
> Given this is
>
> Le lun. 30 janv. 2023 à 07:53, Hervé Boutemy a
>
> écrit :
> > I think that first steps are:
> >
> > 1. release maven-api-meta as a shared component, given it has no
> > dependency
> >
> > https://maven.apache
Given this is
Le lun. 30 janv. 2023 à 07:53, Hervé Boutemy a
écrit :
> I think that first steps are:
>
> 1. release maven-api-meta as a shared component, given it has no dependency
>
> https://maven.apache.org/ref/4.0.0-alpha-4/api/maven-api-meta/dependencies.html
> Eventually renaming it maven-
On Mon, Jan 30, 2023 at 1:53 AM Hervé Boutemy wrote:
>
> I think that first steps are:
>
> 1. release maven-api-meta as a shared component, given it has no dependency
> https://maven.apache.org/ref/4.0.0-alpha-4/api/maven-api-meta/dependencies.html
> Eventually renaming it maven-api-annotations, g
I think that first steps are:
1. release maven-api-meta as a shared component, given it has no dependency
https://maven.apache.org/ref/4.0.0-alpha-4/api/maven-api-meta/dependencies.html
Eventually renaming it maven-api-annotations, given it's the Java package name
inside
2. release maven-api-xml
That sounds like a good plan.
A few observations:
* the usage of the plexus xml classes should be deprecated along with the
v3 model once the v4 api is stabilized and matured imho
* this will introduce a release cycle between maven-core / plexus-utils,
which is not really clean even though it s
+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 "ple
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 Plex
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 cla
+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
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
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é
20 matches
Mail list logo
