At one stage we had a version 3 XSLT but there are no tools to support it and no-one understands it includes me the author. https://youtrack.jetbrains.com/issue/IJPL-112034/Add-support-for-XSLT-3.0-and-XPath-3.1
I had AI convert it to Java and be done with it. Saves configuring another plugin: xml-maven-plugin Delany On Mon, 16 Mar 2026 at 13:45, Gary Gregory <[email protected]> wrote: > On Mon, Mar 16, 2026 at 7:42 AM Elliotte Rusty Harold > <[email protected]> wrote: > > > > On Mon, Mar 16, 2026 at 10:08 AM Björn Raupach <[email protected]> > wrote: > > > > > > Elliot, I don’t want to stir up a hornet’s nest, but could you give me > a > > > specific example of where it would cause a problem? > > > > > > In Maven 3.9.x the namespace declaration never mattered in all the > > > projects I used it with. I fail to understand why it matters in Maven > 4. > > > > > > > The problems pop as soon as you attempt to use XSLT, XPath, XInclude, > > XSD, or any other general purpose XML tool to process pom.xml files. > > If you don't do that and only use Maven's own libraries, you might > > never encounter problems. However, this removes a large ecosystem of > > well developed and supported libraries from our toolboxes. Not > > everyone uses these tools, but those of us who do really miss them. > > I've written my share of XSLT in the distant past, and I can confirm > that namespaces are a pain to deal with (at least in XSLT 1.0). > Writing a stylesheet to handle multiple namespaces sounds like a > nightmare. > > Gary > > > > > This will be more relevant to developers working on Maven itself and > > with non-Maven projects that rely on the Maven repository system (e.g. > > Gradel, bazel) than to Java developers who are simply building their > > projects with Maven. The latter won't have an obvious problem, but > > they will have fewer tools others have built for them, and progress on > > the tool they are using will be slower because Mavend developers can't > > use generic XML tools to do generic XML things and have to burn time > > and resources on more difficult solutions. > > > > Beware the Availability Heuristic. > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
