To be clear, what you get for any given build is a normal pom - just one that was built from the merging of N partial poms - through composition - any given merged pom is exactly what it needs to be, no more, no less, and standard maven post merge.
On Mon, 17 Mar 2025 at 02:50, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > @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 > > > > >
