I've been using Maven for years in projects from tiny to hundered of modules, and I've never had a need for tiles, flagstone, or other countertops ;-)
Is this related to https://tiles.apache.org/ ? Is there a tutorial I can get an idea of what this is? Ty, Gary On Sun, Mar 16, 2025, 09:55 Fred Cooke <fred.co...@gmail.com> wrote: > 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 > > > > >
