Yes, it's too late. I share your frustration with hierarchies, and more than in just the context of build systems. There are a lot of areas in computers where hierarchies are major problems, file systems not least among them. Nonetheless, at this late date Maven and the Maven repository system are simply too baked into the deep layers of almost everything written in the public Java ecosystem, and not a little into internal systems too. Changing this now is a non-starter.
The only path forward is to provide a complete alternative to Maven, and possibly the Maven repository system. It's been done before: gradle, blaze, buck, google3, and probably other systems I'm not familiar with. However any such effort should be its own project, and not part of Maven. Maven itself is too restricted by backwards compatibility. On Sun, Mar 16, 2025 at 8:40 AM Fred Cooke <fred.co...@gmail.com> wrote: > > I'd like to revive this discussion on tiles and possible alternatives. > > I'll say it bluntly: Maven without tiles or an equivalent is not something > I want to use. And yet there's nothing else that comes close, either. > > I've been using Maven since 2006 (2, then 3) and tiles since 2017, > intensely since 2019. > > The parent hierarchy style is a maintenance nightmare that makes flat out > duplicated configurations look good. > > Once you go tiles you never go back. > > I feel like it's time to accept that parent hierarchies are not good enough > and offer some kind of tiles like composition behaviour in core maven as a > first class feature. A core part of the pom. > > Is it too late? Could I dust off my 8 year unused dev skills and help? > > This is a huge deal. Tiles takes maven from a good tool to a genuine > masterpiece. M4 without tiles would be a huge step backwards even if it > improves numerous other things. > > I have read through the following page, and most of it sounds good: > https://maven.apache.org/whatsnewinmaven4.html > > What's the path forward? > > Cheers, > > Fred. > > On Fri, 24 Jan 2025 at 01:39, Elliotte Rusty Harold <elh...@ibiblio.org> > wrote: > > > If we're going to use something like > > mvn:org.apache.maven:maven-snippet:1.0 let's make sure we define the > > scheme with the IANA. > > > > Yes, I suppose you can use id or element pointers without going full XPath. > > > > On Thu, Jan 23, 2025 at 12:24 PM Guillaume Nodet <gno...@apache.org> > > wrote: > > > > > > The XInclude spec does not forbid non local references. > > > See https://www.w3.org/TR/xinclude/#include-location > > > So it could definitely be something like: > > > mvn:org.apache.maven:maven-snippet:1.0 > > > Also, pointers are actually supported as shown by the unit tests [1]. > > > > > > That said, we did choose to only support relative URis (in [2]) > > > and I'm sure it would be a good idea to open it to absolute URIs... > > > > > > [1] > > > > > https://github.com/apache/maven-xinclude-extension/blob/main/src/test/java/org/apache/maven/xinclude/stax/XIncludeTest.java#L111-L117 > > > [2] > > > > > https://github.com/apache/maven-xinclude-extension/blob/main/src/main/java/org/apache/maven/xinclude/LocalXmlResolver.java > > > > > > Le jeu. 23 janv. 2025 à 12:55, Elliotte Rusty Harold <elh...@ibiblio.org> > > a > > > écrit : > > > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <m...@talios.com> > > wrote: > > > > > > > > > > > > > > If the xinclude support could use some form of GAV HREF, rather than > > > > just a > > > > > local file, that might cover the basic requirements/use cases (tho > > some > > > > > users seem to make heavy use of plugin configuration merging over a > > > > series > > > > > of parents). > > > > > > > > XInclude is defined by the XInclude spec, not by Maven. You'd need to > > > > define a completely different inclusion model or perhaps define a new > > > > URI type for Maven GAV coordinates, then add support for this to the > > > > XInclude engines. I'm also not sure what that might mean. Do you > > > > really want to include an entire pom.xml? Probably not, and XPath > > > > fragment identifiers aren't well understood or supported. > > > > > > > > > > > > > > > > -- > > > > Elliotte Rusty Harold > > > > elh...@ibiblio.org > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > -- > > > ------------------------ > > > Guillaume Nodet > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
