You are *severely* downplaying what tiles are used for - it's not "parent duplication avoidance" it's an entirely new paradigm and when fully leveraged it leaves everything else for dead.
Tiles: An app in a set of apps - one line - GAV A set of apps or an app in an environment - one line - GAV A build configuration, repos, etc - used by range within a team/org, changed in one place, applied to all A one-line way to say "this project is of type X" and get that build configuration, multiply this by dozens A cross cutting concern of any type - usable anywhere A set of unrelated cross cutting concerns, a recipe, to serve some purpose A one line way of adding optional features to an otherwise standard build for a project that's a little different to the rest etc etc. With tiles you get the cleanest ecosystem possible. Without you get a bad taste in your mouth and a tool that is 10% as versatile. Very much worth it. Does not require any change to the existing content out there, would be hidden by the build vs consumer pom arrangement just as all the other bits no one wants to know about will be. Maven can be used as generic tooling not for building J apps, but for building/packaging anything at all, period. With that and tiles, the world is your oyster. Without it it's extremely limited. On Mon, 17 Mar 2025 at 02:43, Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > Adding more features to Maven increases the complexity of Maven more > than linearly., There's more to document, more to test, and most > importantly more to understand for anyone trying to get a handle on > Maven. It is simply not worth the additional complexity it introduces. > > Equally importantly, adding new elements like tiles to the POM format > breaks existing code and tools (not just Maven) that processes pom.xml > files. Doing this requires a truly compelling reason, and avoiding > duplication in parent poms isn't it. > > It's possible that what you're trying to achieve could be equally well > achieved by appropriate use of XInclude, though Maven's borked > namespace handling might prevent that. > > On Sun, Mar 16, 2025 at 1:28 PM Fred Cooke <fred.co...@gmail.com> wrote: > > > > Why not simply adopt the existing widely used tile system - but not > require > > the plugin anymore, have a POM 4.1 or 4.2 or whatever that has a <tiles> > > element. > > > > On Mon, 17 Mar 2025 at 01:53, Elliotte Rusty Harold <elh...@ibiblio.org> > > wrote: > > > > > 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 > > > > > > > > > > -- > 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 > >
