@Fred from what I recall, tile system was actually not that widely used and doesn't exactly embraces maven configuration style so it needs more effort than just copying the code if it is what you had in mind. Also I do not think we should promote more than needed such pattern which makes builds more complicated but more enable it for cases where builds are complicated. Normally all is needed to do it so if you find some blockers in v4 API and extension mechanism we can address it but making it a core feature is the promise of becoming like gradle and a one guy per build kind of solution which is against the spirit of maven having more conventions. To be revised for maven 5 maybe but I think v4 would be too early since it changes already a lot of things.
So long story short: IMHO we must enable it but not provide it in org.apache.maven. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Le dim. 16 mars 2025 à 14:43, Elliotte Rusty Harold <elh...@ibiblio.org> a écrit : > 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 > >
