Is this really the right thing to do? We should rather encapsulate our stuff, no?

Is this really the right thing to do? We should rather encapsulate our stuff, no?

What do you mean by "our stuff" ? The plexus xml bits ? The goal is not expose the plexus xml bits anymore. In order to do so, a new api has been introduced in maven 4. For compatibility, the old plexus has to be rewritten on top of this new api, else maven and plugins won't be able to share any xml config.
Maybe I'm missing something though...

Is this really the right thing to do? We should rather encapsulate our stuff, no?

What do you mean by "our stuff" ? The plexus xml bits ? The goal is not expose the plexus xml bits anymore. In order to do so, a new api has been introduced in maven 4. For compatibility, the old plexus has to be rewritten on top of this new api, else maven and plugins won't be able to share any xml config. Maybe I'm missing something though...

Ah, you are leaving this as a hull/wrapper to the "new" solution?

Is this really the right thing to do? We should rather encapsulate our stuff, no?

What do you mean by "our stuff" ? The plexus xml bits ? The goal is not expose the plexus xml bits anymore. In order to do so, a new api has been introduced in maven 4. For compatibility, the old plexus has to be rewritten on top of this new api, else maven and plugins won't be able to share any xml config. Maybe I'm missing something though...

Ah, you are leaving this as a hull/wrapper to the "new" solution?

Exactly. The new Xpp3Dom would wrap the maven 4 XmlNode interface and the Xpp3DomBuilder and Xpp3DomUtils delegate to the maven api.

so it means using this with maven 3.9.x and maven 3.9.x will have a dependency on maven 4.x.x 🤣

notice that in previous conversations, I proposed to split plexus-utils 3.x into plexus-utils 4.x + plexus-xml 4.x (containing org.codehaus.plexus.utils.xml packages) to at least have the current tweaks only happen on the plexus-xml side

but this step was conflated with other (independently valid) ones, and now we are adding many Maven dependencies to the full plexus-utils, which may not be great for basic "non-XML" use of plexus-utils

notice that in previous conversations, I proposed to split plexus-utils 3.x into plexus-utils 4.x + plexus-xml 4.x (containing org.codehaus.plexus.utils.xml packages) to at least have the current tweaks only happen on the plexus-xml side

but this step was conflated with other (independently valid) ones, and now we are adding many Maven dependencies to the full plexus-utils, which may not be great for basic "non-XML" use of plexus-utils

Well, let's create a plexus-xml repo then and do the switch in it.

notice that in previous conversations, I proposed to split plexus-utils 3.x into plexus-utils 4.x + plexus-xml 4.x (containing org.codehaus.plexus.utils.xml packages) to at least have the current tweaks only happen on the plexus-xml side
but this step was conflated with other (independently valid) ones, and now we are adding many Maven dependencies to the full plexus-utils, which may not be great for basic "non-XML" use of plexus-utils

Well, let's create a plexus-xml repo then and do the switch in it.

Will users migrating to plexus-utils 4.x have to a new dependency on plexus-xml 4.x, or were you thinking about adding this dependency so that the migration could be done seamlessly ? Another way to tackle the problem would be split plexus-utils into plexus-xml and plexus-utils-core and keep plexus-utils with the two dependencies so that users could migrate easily...

Will users migrating to plexus-utils 4.x have to a new dependency on plexus-xml 4.x

to me, they'd have to evaluate if they use the xml API or not, then choose if they add plexus-xml or not while upgrading plexus-utils to 4.x for all other utilities

split from plexus-utils 3 to plexus-utils 4 + plexus-xml 4 prototyped in 2 plexus-utils branches:
https://github.com/codehaus-plexus/plexus-utils/tree/plexus-utils-4
https://github.com/codehaus-plexus/plexus-utils/tree/plexus-xml-4

There was 1 small unexpected change to do: move ReaderFactory/WriterFactory from o.c.plexus.util to o.c.plexus.util.xml

If we find this split useful to ease our Maven core XML changes, plexus-utils-4 is meant to become master of plexus-utils.
And plexus-xml-4 is meant to become a separate Git repo

(notice: it is what happened in the past with interpolation, which was extracted from an o.c.plexus.interpolation package in plexus-utils to plexus-interpolation Git repo)

WDYT?

split from plexus-utils 3 to plexus-utils 4 + plexus-xml 4 prototyped in 2 plexus-utils branches: https://github.com/codehaus-plexus/plexus-utils/tree/plexus-utils-4 https://github.com/codehaus-plexus/plexus-utils/tree/plexus-xml-4

There was 1 small unexpected change to do: move ReaderFactory/WriterFactory from o.c.plexus.util to o.c.plexus.util.xml

If we find this split useful to ease our Maven core XML changes, plexus-utils-4 is meant to become master of plexus-utils. And plexus-xml-4 is meant to become a separate Git repo

WDYT?

Très bien !

split from plexus-utils 3 to plexus-utils 4 + plexus-xml 4 prototyped in 2 plexus-utils branches: https://github.com/codehaus-plexus/plexus-utils/tree/plexus-utils-4 https://github.com/codehaus-plexus/plexus-utils/tree/plexus-xml-4

There was 1 small unexpected change to do: move ReaderFactory/WriterFactory from o.c.plexus.util to o.c.plexus.util.xml

If we find this split useful to ease our Maven core XML changes, plexus-utils-4 is meant to become master of plexus-utils. And plexus-xml-4 is meant to become a separate Git repo

(notice: it is what happened in the past with interpolation, which was extracted from an o.c.plexus.interpolation package in plexus-utils to plexus-interpolation Git repo)

WDYT?

I've experimented porting maven with those libraries, here are a few points:

• the ReaderFactory is used in the code generated by modello for the xml reader, this means the generators won't be compatible with the new libraries. For maven, this may mean switching to velocity templates to generate the readers
• we still have a cycle : plexus-xml would use the XmlNode from maven 4, which itself requires the pull parser from plexus-xml

The second point is a bit of a problem I think. I wonder if we should split the pull parser only in plexus-xml and keep the Xpp3Node as a wrapper around the maven XmlNode inside plexus-utils...

If we want to keep other xml related classes, we could split in 3 parts:

• plexus-xml-pull : the pull parser, i.e. the org.codehaus.plexus.util.xml.pull package
• plexus-xml : the xml related classes, i.e. the org.codehaus.plexus.util.xml package, which would delegate to maven-xml-impl, reusing plexus-xml-pull
• plexus-utils

Note that the original point is to keep maven 3.x plugins working on maven 4, so I'm a bit worried of any incompatibility, in particular, moving the ReaderFactory used by modello generated xml readers sounds worrying, but I think the compatibility needs are restricted to 5 classes.

One possibility to fix the ReaderFactory problem would be to add a @Deprecated org.codehaux.plexus.ReaderFactory class in plexus-xml that would delegate to the new org.codehaux.plexus.xml.ReaderFactory class.

It is a very bad idea to move classes around from one Maven artifact to another without renaming them. This causes major problems when more than one instance ends up in the classpath at the same time and Java selects the wrong one, if it doesn't just give up and exit (which it can do in Java 9+). The classes need to be renamed, not just the artifacts.

The goal is to provide some compatibility. In the future, plugins should use the new maven 4 api with the XmlNode, not the plexus Xpp3Node. So there's no point in creating a new package which should not be used at all.

The key is the fully qualified class name including the package name. If that is in fact different, then there's no problem, and I withdraw my objection.

Although now that I think about it...you can still have a problem if the same package (subpackages count as different packages for this) is split across two different jars. That causes problems too.

The key is the fully qualified class name including the package name. If that is in fact different, then there's no problem, and I withdraw my objection.

Although now that I think about it...you can still have a problem if the same package (subpackages count as different packages for this) is split across two different jars. That causes problems too.

@elharo I think you misunderstand the problem. Here's a small recap.

The new maven 4 api provides an immutable xml api org.apache.maven.api.xml.XmlNode. In order to support maven 3.x plugins, the existing implementation, i.e. org.codehaus.plexus.xml.Xpp3Node has been rewritten on top of the XmlNode. That's done in maven-xml-impl. To ease compatibility, the org.codehaus.plexus:plexus-utils had been originally repackaged in maven and modified as org.apache.maven:plexus-utils in a later alpha release. That means that maven 4 uses its own copy of the Xpp3Node (which is different from the plexus-utils one) and expose that class to plugins (that's part of the few classes exported from the maven core class loader to plugins). Plugins that have a dependency on plexus-utils will therefore have different copy of that class, the maven one being the one used, following the plexus class loader rules controlled by maven.
We do all agree that's definitely not an ideal state and we're trying to find a way round. The rough idea was to move the maven's own version of Xpp3Node back into plexus-utils. But to avoid cycles between artifacts, a split is necessary.

Note that the final state will be that all plugins will use the new maven 4 api with XmlNode and Xpp3Node will not be used anymore. So the goal is to clean things as much as possible while keeping compatibility, else plugins can directly migrate to the clean final state. If any transition between both is seen as as unclean as the current state, so be it, and we just keep duplicate classes / artifacts across maven / plexus, but it was seen as more complicated, especially in terms of maintenance. So we are looking at a way to reduce class duplication without breaking compatibility, just as a slightly cleaner transition between the current state and the point at which all plugins would have migrated to the v4 api.

So to get back to your original point, the discussion is exactly about moving classes from plexus-utils to a new plexus-xml to break the code duplication between maven and plexus-utils. If you have a better option, I'd be really glad to discuss it.

I keep getting confused as to what is and is not moving how. However. my bottom line is that the same fully qualified class name should not be published in different artifacts, ever. Once com.example.Something has been publicly released in foo:bar:0.6.2 it should never be published in foo2:baz:x.x

If you need to change things the way forward is to change BOTH the fully package qualified classnames AND the Maven groupID:artifactID. It is not possible to release a drop-in replacement under a different group ID or artifact ID without causing very painful, very hard-to-debug problems for end users and dependents.

If we're not doing that, fine. If we are doing that, it's time to go back to the drawing board.

https://jlbp.dev/JLBP-6

That has been done, and we're on the drawing board to fix the problems. But if you don't want to find the less worst way forward, we'll keep the current state, which is that maven publishes org.apache.maven:plexus-utils which is almost a clone of org.codehaus.plexus:plexus-utils.

sadly yes :(

Here's part of what I see in the jar for org.apache.maven:plexus-utils:

 80291 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/FileUtils.java
 32945 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/IOUtil.java
 12054 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/InterpolationFilterReader.java
 14693 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/LineOrientedInterpolatingReader.java
  4763 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/MatchPattern.java
  2885 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/MatchPatterns.java
  4490 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/NioFiles.java
 13584 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/Os.java
 19740 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/PathTool

Is there some plan to change this? This is exactly what's going to cause dependency conflicts and classpath breakages for clients.

Here's part of what I see in the jar for org.apache.maven:plexus-utils:

 80291 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/FileUtils.java
 32945 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/IOUtil.java
 12054 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/InterpolationFilterReader.java
 14693 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/LineOrientedInterpolatingReader.java
  4763 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/MatchPattern.java
  2885 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/MatchPatterns.java
  4490 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/NioFiles.java
 13584 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/Os.java
 19740 Fri Jan 27 15:32:50 EST 2023 org/codehaus/plexus/util/PathTool

Is there some plan to change this? This is exactly what's going to cause dependency conflicts and classpath breakages for clients.

That's what we were trying to do since a few months, but each time we suggest something, you keep insisting the state (present or suggested) breaks some rule and we should definitely not go in that direction.

Once again, the goal is to remain binary compatible, i.e. allow existing plugins to work on maven 4.x. That cause a bunch of constraints, in particular, the fact that the Xpp3Dom class from plexus-utils needs to be built on top of the XmlNode from maven-api-xml (which is what currently drove the repackaging of the plexus-utils inside maven). The goals of this PR and the discussion is about how to avoid class duplication and move this wrapping in the plexus land somehow.

And the ultimate state is that plugins will use the maven 4 api, so Xpp3Dom would ultimately be deprecated, or at least not exported by maven and bound to the XmlNode.

And the ultimate state is that plugins will use the maven 4 api, so Xpp3Dom would ultimately be deprecated, or at least not exported by maven and bound to the XmlNode.

Yes, ultimately as "in Maven 5 or 6", because it requires all plugins to upgrade to the new Maven 4 API = something that will take a long time before we can just cut the past and say "old plugins using Maven 3 API cannot run any more"... (just for reference, just removing in Maven 3.9.0 the old plexus-utils injection trick from Maven 2 is causing complaints for dead plugins: see https://issues.apache.org/jira/browse/MNG-6965 )

for the near future, with existing Maven plugins of the next few years using Maven 3 plugin API before they migrate to Maven 4 API, the classloading of Maven core (core and API classloaders) protects them from dependency conflicts and classpath breakages

I keep coming back to the same point: If the artifact ID or group ID of an existing class is changed, the fully package qualified name of the class should be changed too. If you want to remain binary compatible, you need to keep the fully package qualified name AND the group and artifact IDs the same. There is no way around this. The existing scheme that moves the classes into a new Maven artifact is NOT binary compatible. It will cause dependency conflicts and runtime and compile time breakages that do not currently occur. Some of these are extremely hard to diagnose and debug and cause much developer pain.

I have no particular concern about new classes or implementation details inside classes. If Xpp3Dom now depends on a new XmlNode class that didn't exist before, fine. But the existing org.codehaus.plexus.util.xml.Xpp3Dom from org.codehaus.plexus:plexus-utils should not also be published in org.apache.maven:plexus-utils. That will lead to multiple versions being included in the classpath, and which one will be selected is hard to guess. Furthermore, Maven and Gradle will not necessary select the same version of this class given the same pom.xml. In JDK 9+ this can turn into a compile or runtime error due to split packages. This is sometimes called overlapping classes, and it's cumbersome to debug and workaround even if you're expecting it. If you're not familiar with it, it can take days or weeks to figure out what's happening.

https://jlbp.dev/JLBP-5

I keep coming back to the same point: If the artifact ID or group ID of an existing class is changed, the fully package qualified name of the class should be changed too. If you want to remain binary compatible, you need to keep the fully package qualified name AND the group and artifact IDs the same. There is no way around this. The existing scheme that moves the classes into a new Maven artifact is NOT binary compatible. It will cause dependency conflicts and runtime and compile time breakages that do not currently occur. Some of these are extremely hard to diagnose and debug and cause much developer pain.

I don't care about compile time breakages. What I'd like to achieve is 99% runtime compatibility.

I have no particular concern about new classes or implementation details inside classes. If Xpp3Dom now depends on a new XmlNode class that didn't exist before, fine. But the existing org.codehaus.plexus.util.xml.Xpp3Dom from org.codehaus.plexus:plexus-utils should not also be published in org.apache.maven:plexus-utils.

Thanks, but once again, that's the current state. Stating that it's not good does not really help, we all know this, and we'd like to get past it.

That will lead to multiple versions being included in the classpath, and which one will be selected is hard to guess.

In theory yes, but in reality, that's not true, because maven controls the classloader of plugins. And the class exported by maven's own classloader will take precedence over the one from the plugin classloader, so this definitely works.

Furthermore, Maven and Gradle will not necessary select the same version of this class given the same pom.xml. In JDK 9+ this can turn into a compile or runtime error due to split packages. This is sometimes called overlapping classes, and it's cumbersome to debug and workaround even if you're expecting it. If you're not familiar with it, it can take days or weeks to figure out what's happening.

Yes, that's exactly what we're trying to fix. It's also a pain in terms of maintenance.

So, can we get past the rules and try to find a lesser evil here ?

There are multiple ways forward, but basically, the idea is to bring back the change from maven 4 into the plexus xml classes in the plexus source tree, instead of duplicating the class in maven. That will allow us to get rid of the repackaged artifact in maven and should bring us back to a cleaner state.

• bring the changes directly in plexus-utils : this will add a dependency from plexus-utils to maven-api-xml and maven-xml-impl. The benefit is that classes are not moved around, the drawback is that it creates a cycle because maven-xml-impl has a dependency on plexus-utils (this does not seem to be a JLBP-covered rule though, but that's still clearly bad)

• split plexus-utils in multiple part to break the cycle: this may need to extract the pull parser in a different jar and the other other xml files. This would require a bit of adaptation and would most probably break JLBP-6 and JLBP-19. This is @hboutemy suggestion.

I personally don't care so much about which solution we favour, but I'd really like to go forward on fixing the current state.

next try:

• plexus-utils 4, now keeping Reader/WriterFactory as deprecated master...plexus-utils-4
• plexus-xml 4, master...plexus-xml-4

extracting plexus-xml-pull from plexus-xml seems not feasible because there are many classes uses crossing packages

@gnodet do you think these 2 would make sense and ease Maven 4 core maintenance on the XML compatibility update?

@hboutemy fwiw, the ReaderFactory from plexus-utils-4 is incompatible and will break xml readers generated by modello

Here's a branch that update maven to the two branches you created:
https://github.com/gnodet/maven/tree/plexus-utils-4
To make it build, I had to create a few ReaderFactory to support the newXmlReader method which is used by the modello generated code. A cleaner fix would be to allow modello to use either org.codehaus.plexus.util.ReaderFactory or org.codehaus.plexus.util.xml.ReaderFactory during generation, or to switch to velocity template in maven for those bits that are still generated using modello.

@gnodet yes, I had to remove the methods using org.codehaus.plexus.utils.xml.XmlReader from org.codehaus.plexus.utils.ReaderFactory because it created an unwanted dependency from plexus-utils-4 to plexus-xml-4 for stupid small helpers master...plexus-utils-4#diff-e8873e56f33439d5ead6708af62e7783cd0f4f9f36e7839ca96e7da0d14c5002L105

IMHO, the easiest update in Modello to support the change is to avoid using this ReaderFactory.newXmlReader(InputStream) method and just call instead directly new XmlReader(InputStream): this will be backward and forward compatible without much boilerplate generation

If we need to do that, I'm even not sure that deprecating org.codehaus.plexus.utils.ReaderFactory (with the few methods removed) from plexus-utils-4 in favor of org.codehaus.plexus.utils.xml.ReaderFactory (with the original methods) in plexus-xml-4 really makes sense: we can just keep the original one, isn't it?

@gnodet yes, I had to remove the methods using org.codehaus.plexus.utils.xml.XmlReader from org.codehaus.plexus.utils.ReaderFactory because it created an unwanted dependency from plexus-utils-4 to plexus-xml-4 for stupid small helpers master...plexus-utils-4#diff-e8873e56f33439d5ead6708af62e7783cd0f4f9f36e7839ca96e7da0d14c5002L105

IMHO, the easiest update in Modello to support the change is to avoid using this ReaderFactory.newXmlReader(InputStream) method and just call instead directly new XmlReader(InputStream): this will be backward and forward compatible without much boilerplate generation

Yes, very good idea.

If we need to do that, I'm even not sure that deprecating org.codehaus.plexus.utils.ReaderFactory (with the few methods removed) from plexus-utils-4 in favor of org.codehaus.plexus.utils.xml.ReaderFactory (with the original methods) in plexus-xml-4 really makes sense: we can just keep the original one, isn't it?

I don't follow. The original one is in plexus-utils and does not have access to plexus-xml atm, unless we add a (optional) dependency from plexus-utils to plexus-xml in which case the whole point is mute and nothing needs to be done.
This may actually be the easiest option (which does not prevent improving modello to go straight to the new XmlStreamReader() call obviously.

I also think we should deprecate it, regardless of other considerations. The MXParser does create an XmlStreamReader when given an InputStream, so there's absolutely no reason for users to create the XmlStreamReader explicitly and they should rather pass the InputStream directly using parser.setInput(inputStream, null).

oh, optional dependency to plexus-xml-4, why not: I did not imagine this one, looks reasonable

Isn't the convention to call it {name}N? E.g., commons-lang4 instead of the hyphen in between?

Isn't the convention to call it {name}N? E.g., commons-lang4 instead of the hyphen in between?

I don't think we need to have the 4 in the artifactId, I assumed it was a shortcut to indicate version 4.0.0, nothing more.

Isn't the convention to call it {name}N? E.g., commons-lang4 instead of the hyphen in between?

I don't think we need to have the 4 in the artifactId, I assumed it was a shortcut to indicate version 4.0.0, nothing more.

Alright, makes sense. Otherwise it'd be another GAV.

Update:

• plexus-xml 4 master...plexus-xml-4 update with the switch to maven's XmlNode and implementation
• plexus-utils 4, deprecating Reader/WriterFactory and adding an optional dependency on plexus-xml for compatibility master...plexus-utils-4
• updated maven branch removing the duplicated plexus classes / repackaging

Note that two unit tests are failing in plexus-xml with the switch to maven's XmlNodeImpl, so I need to investigate a bit.

plexus-utils-4 and plexus-xml-4 are branch names of plexus-utils.git: will become master of plexus-utils.git and plexus-xml.git
we need to define when we are convinced enough to do the move

Here's a fix for the failing unit tests.

The behavior has changed with #216 but plexus-utils contains duplicate xml merge code in Xpp3Dom and Xpp3DomUtils and the two pieces have diverged. This duplication is removed by the PR by switching to the XmlNode implementation in both cases, but we now need to fix the expectations.

We may want to run the full maven IT suite before merging, but it looks good to me otherwise.

@hboutemy I've been running the maven integration test suite successfully with the 3 branches above.
If you're ok, I can go ahead, fork the current repo and apply the plexus PRs.

great, yes, please create plexus-xml.git
and I'd like that we have 2 branches in it: before Maven XML API introduction, and after
I don't know if the releases will be 4.0.0 and 4.1.0, or 3.0.0 and 4.0.0: any preference?

great, yes, please create plexus-xml.git
and I'd like that we have 2 branches in it: before Maven XML API introduction, and after
I don't know if the releases will be 4.0.0 and 4.1.0, or 3.0.0 and 4.0.0: any preference?

I'm not really keen on duplicating the code, I thought the idea was to reduce maintenance ;-)
This would mean we'd have to possibly maintain the Xpp3Node / XmlNodeImpl in:

• plexus-utils 3.x
• plexus-xml 3.x
• maven-xml-impl 4.x
  What's the use case for plexus-xml 3.x ? can't we just use plexus-utils 3.x as it's now ?

yes, reducing maintenance is important

I want to full stop plexus-utils 3.x maintenance, replaced with split in plexus-utils 4.x and plexus-xml 3 (or other version = the question I was asking), just to have separate releases for the XML part vs the non-XML part

and maintain the new plexus-xml 4 with maven-xml-impl 4.x, yes

yes, reducing maintenance is important

I want to full stop plexus-utils 3.x maintenance, replaced with split in plexus-utils 4.x and plexus-xml 3 (or other version = the question I was asking), just to have separate releases for the XML part vs the non-XML part

and maintain the new plexus-xml 4 with maven-xml-impl 4.x, yes

Sounds good. I think a version 3 for plexus-xml would be weird, I'd rather align it with the next plexus-utils (i.e. 4, as it is now), or start again from 1. But 4 definitely sounds good.
I've create the plexus-xml repository, pushed the changed in master there, and also created a branch for plexus-utils-3.x and pushed the changes in master too. I haven't been able to deploy snapshots yet, and oss.sonatype.org seems down at the moment...

great job, thanks
we'll see if this plexus-xml release before maven-xml-impl switch looks useful or not later

Yes, great job.

After preparing releases would be good to send recommendations - what artefact should be used where for our/user plugins or libs. Something that we must do now or something for near future (transition to mvn4 API).
Probably m-plugin-plugin will be impacted most.

I would skip most exciting part of Maven4 internals ;-) that will be more important when we bump minimal supported Maven version.

Yes, great job.

After preparing releases would be good to send recommendations - what artefact should be used where for our/user plugins or libs. Something that we must do now or something for near future (transition to mvn4 API). Probably m-plugin-plugin will be impacted most.

I would skip most exciting part of Maven4 internals ;-) that will be more important when we bump minimal supported Maven version.

AFAIK, adding the dependency to plexus-xml is the only real change needed for people that are using the xml parts in plexus-utils 3.x. If we want to minimise the impact, we can change the plexus-utils dependency to plexus-xml to a non optional one, so that it will be automatically brought in via transitive dependencies.
That makes the upgrade to plexus-utils 4.x completely transparent (at least for m-plugin-tools which I've just tested...)

I prefer having users add plexus-xml dependency if they need it

Done