apache
Migrate off jdom2 and use the DOM parser/builder built into the JDK instead
New feature, improvement proposal
Currently archetype-common uses jdom2 in the MavenJDOMWriter and associated utility classes, AFAICT mainly write a pom in DefaultPomManager.writePom().
In order to reduce the dependency footprint, would it be possible to migrate off jdom2 and use the DOM-parser/builder built into the JDK instead? Or are there particular reasons to use jdom(2) instead?
If you consider MavenJDOMWriter or the associated utility classes as part of the API, for now, it could just be deprecated and a colocated MavenDOMWriter could be added, which is used by archetype and the dependency to jdom2 could be made optional.
Nothing per se, it's just the fact that it's a dependency (which again has dependencies), while the JDK provides something out of the box, which seems to be a direct replacement. And therefore I was wondering if there is a reasons to stay on jdom2, besides that somebody has to do the migration?
For example in the Eclipse simulations release we have jdom2 and jaxen, just because M2E bundles maven-archetype and it depends on jdom2. And while there is nothing wrong with it in particular, I think it's good to reduce dependencies where reasonably possible.
Hm, are we talking about same jdom2? As jdom2 has no effective dependencies at all: https://repo.maven.apache.org/maven2/org/jdom/jdom2/2.0.6.1/jdom2-2.0.6.1.pom (well, they are optional ~~and not needed on "modern" Java, like 8~~ I may be wrong here)
As jdom2 has no effective dependencies at all: https://repo.maven.apache.org/maven2/org/jdom/jdom2/2.0.6.1/jdom2-2.0.6.1.pom (well, they are optional ~and not needed on "modern" Java, like 8~ I may be wrong here)
Yes, I think so. Maybe this is also because the OSGi metadata we generate for jdom2 at Eclipse is too eager. At the moment it has a hard dependency (in the OSGi world) on Jaxen. The other (in Maven) optional dependencies indeed do not exist in the OSGi metadata. But regarding jaxen, I'm not very familiar with jdom2, but is it really possible to avoid it on modern java? Bcause I see no alternative for it in (Unless one provides it's own implementation): https://github.com/hunterhacker/jdom/blob/c6065f684bdff5cebf5f23b2859c5e4c89fd89db/core/src/java/org/jdom2/xpath/XPathFactory.java#L118-L131
But even if it's possible to get rid of jaxen, there would still be jdom2 itself. And I would again wonder if it would be possible to avoid that too? :)
I don't think anything in Maven uses jaxen.
There's some public API that will be a pain to get rid of. It shouldn't have been pubic in the first place, but people keep making that mistake. :-(
