You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Tamás Cservenák <ta...@cservenak.net> on 2025/01/22 15:25:02 UTC
What is new in Maven 4?
Howdy,
Lately, we get this question quite often.
Today Guillaume assembled this very informative presentation:
https://gnodet.github.io/maven4-presentation/
There is also ongoing effort to assemble a page on Maven site as well:
https://github.com/apache/maven-site/pull/598
Have fun
T
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: What is new in Maven 4?
Posted by ma...@barclays.com.INVALID.
Re: slides: maven 4 sounds so nice!
-----Original Message-----
From: Tamás Cservenák <ta...@cservenak.net>
Sent: Wednesday, January 22, 2025 10:25 AM
To: Maven Users List <us...@maven.apache.org>; Maven Developers List <de...@maven.apache.org>
Subject: What is new in Maven 4?
CAUTION: This email originated from outside our organization - users-return-148923-Mark.Yagnatinsky=barclays.com@maven.apache.org Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe.
______________________________________________________________________
Howdy,
Lately, we get this question quite often.
Today Guillaume assembled this very informative presentation:
https://urldefense.com/v3/__https://gnodet.github.io/maven4-presentation/__;!!G7x19LdBoP0e!nsf5VzhumhgRlECvjkQkk-Pu_n8dG4Usrizg-h9TQfcTcSglIgJzVS6xvbLiL77_tiJIKYp69MRDXYowDjNadwOs$
There is also ongoing effort to assemble a page on Maven site as well:
https://urldefense.com/v3/__https://github.com/apache/maven-site/pull/598__;!!G7x19LdBoP0e!nsf5VzhumhgRlECvjkQkk-Pu_n8dG4Usrizg-h9TQfcTcSglIgJzVS6xvbLiL77_tiJIKYp69MRDXYowDrRFYpqS$
Have fun
T
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html.
For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://publicresearch.barclays.com.
__________________________________________________________________________________
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html.
__________________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
AFAIK maven 4 was intended to support it as a first citizen thanks to
extension mechanism so if anything doesn't work we must enhance the maven 4
api to support it else we would have missed the v4 promotion when getting
final IMHO.
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 à 13:55, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> 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 <fr...@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 <el...@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 <gn...@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 <
> elharo@ibiblio.org>
> > > a
> > > > écrit :
> > > >
> > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is new in Maven 4?
Posted by Mark Derricutt <ma...@talios.com>.
On 17 Mar 2025 at 2:42:25 AM, Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> 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.
>
XInclude *would* work - *if* it supported pulling remote artefacts and not
just local files (which I believe is a current limitation. One solution
there would be to require some other process to synchronise files to
include.
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
I've pushed an update POC at
https://github.com/apache/maven/pull/1209
There are clearly some things to adjust.
I'd be happy with a quick look from people experienced with tiles to check
that it makes sense.
Le lun. 17 mars 2025 à 09:17, Fred Cooke <fr...@gmail.com> a écrit :
> I didn't summarise why it doesn't belong in maven, I summarised existing
> uses across dozens of companies past and present. This is the current
> reality for sophisticated users of the tiles plugin with M3. Not some pie
> in the sky dream. I'm here because it sounded to me like that wasn't a
> guaranteed future and that's not a future I want to see.
>
> New paradigm to some readers, near decade old paradigm to some others.
>
> It's a core issue in the architecture of maven that motivated tiles,
> mixins, and the like - it seems to me that the ultimate place to fix that
> 20 year old design issue is IN Maven and put it to rest once and for all,
> authoritatively, from the source.
>
> But as long as there's some way of achieving the same effects, that's fine.
> Ideally keeping the existing tile ecosystems usable and not having to
> reengineer and release every single one in some new format/style - but
> even that would be better than not having equivalent functionality
> available in some form.
>
> Thanks to everyone actively discussing this - I truly appreciate it. Tiles
> has literally been life-changing for me, I value it more than words can
> describe.
>
>
>
> On Mon, 17 Mar 2025 at 03:14, Elliotte Rusty Harold <el...@ibiblio.org>
> wrote:
>
> > On Sun, Mar 16, 2025 at 1:55 PM Fred Cooke <fr...@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.
> >
> > Thanks for summarizing why this doesn't belong in Maven. An entirely
> > new paradigm needs an entirely new tool and platform. It shouldn't try
> > to work inside and be limited by compatibility with the old tool and
> > platform.
> >
> > I wouldn't be all that surprised if this is a better build system than
> > Maven, but it doesn't need to be in Maven.
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Fred Cooke <fr...@gmail.com>.
I didn't summarise why it doesn't belong in maven, I summarised existing
uses across dozens of companies past and present. This is the current
reality for sophisticated users of the tiles plugin with M3. Not some pie
in the sky dream. I'm here because it sounded to me like that wasn't a
guaranteed future and that's not a future I want to see.
New paradigm to some readers, near decade old paradigm to some others.
It's a core issue in the architecture of maven that motivated tiles,
mixins, and the like - it seems to me that the ultimate place to fix that
20 year old design issue is IN Maven and put it to rest once and for all,
authoritatively, from the source.
But as long as there's some way of achieving the same effects, that's fine.
Ideally keeping the existing tile ecosystems usable and not having to
reengineer and release every single one in some new format/style - but
even that would be better than not having equivalent functionality
available in some form.
Thanks to everyone actively discussing this - I truly appreciate it. Tiles
has literally been life-changing for me, I value it more than words can
describe.
On Mon, 17 Mar 2025 at 03:14, Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Sun, Mar 16, 2025 at 1:55 PM Fred Cooke <fr...@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.
>
> Thanks for summarizing why this doesn't belong in Maven. An entirely
> new paradigm needs an entirely new tool and platform. It shouldn't try
> to work inside and be limited by compatibility with the old tool and
> platform.
>
> I wouldn't be all that surprised if this is a better build system than
> Maven, but it doesn't need to be in Maven.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is new in Maven 4?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sun, Mar 16, 2025 at 1:55 PM Fred Cooke <fr...@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.
Thanks for summarizing why this doesn't belong in Maven. An entirely
new paradigm needs an entirely new tool and platform. It shouldn't try
to work inside and be limited by compatibility with the old tool and
platform.
I wouldn't be all that surprised if this is a better build system than
Maven, but it doesn't need to be in Maven.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
I think the correct pointer is
https://github.com/repaint-io/maven-tiles
Le dim. 16 mars 2025 à 16:48, Gary Gregory <ga...@gmail.com> a
écrit :
> 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 <fr...@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 <el...@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 <fr...@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 <
> > elharo@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 <fr...@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 <
> > > elharo@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 <
> > > gnodet@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 <
> > > > > elharo@ibiblio.org>
> > > > > > > a
> > > > > > > > écrit :
> > > > > > > >
> > > > > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <
> > > mark@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
> > > > > > > > > elharo@ibiblio.org
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > ------------------------
> > > > > > > > Guillaume Nodet
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Elliotte Rusty Harold
> > > > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Gary Gregory <ga...@gmail.com>.
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 <fr...@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 <el...@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 <fr...@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 <
> elharo@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 <fr...@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 <
> > elharo@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 <
> > gnodet@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 <
> > > > elharo@ibiblio.org>
> > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <
> > mark@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
> > > > > > > > elharo@ibiblio.org
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ------------------------
> > > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Elliotte Rusty Harold
> > > > > > elharo@ibiblio.org
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: What is new in Maven 4?
Posted by Fred Cooke <fr...@gmail.com>.
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 <el...@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 <fr...@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 <el...@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 <fr...@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 <
> elharo@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 <
> gnodet@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 <
> > > elharo@ibiblio.org>
> > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <
> mark@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
> > > > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is new in Maven 4?
Posted by Fred Cooke <fr...@gmail.com>.
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 <rm...@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 <el...@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 <fr...@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 <
> elharo@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 <fr...@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 <
> > elharo@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 <
> > gnodet@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 <
> > > > elharo@ibiblio.org>
> > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <
> > mark@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
> > > > > > > > elharo@ibiblio.org
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ------------------------
> > > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Elliotte Rusty Harold
> > > > > > elharo@ibiblio.org
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
I don't think tiles can be implemented just using a parser.
The ModelParser SPI provides a way to read a file into an existing *file*
model, but it does not handle parent hierarchy merging, profiles injection,
property substitution, etc... All those things are done by the ModelBuilder
which delegates to the default model reader or the ModelParser SPI.
For mixins (as I implemented a while ago in my POC), the model builder
needs to be changed. That piece is particularly complex and hard to
extend. Of course, it could be copied / enhanced, but the maintenance
would be a nightmare.
In addition, the ModelParser is currently used very early in the process
and is not given a Session which could be used to actually download the
tiles/mixins.
I'll try to rewrite the POC on top of rc-3 asap.
Le lun. 17 mars 2025 à 08:02, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> >> And it just breaks all editors and IDE out there except the almost no
> >> more used netbeans ;)
> >
> > Does it?
>
> At least m2e should work with tiles extension (basically with any
> extension).
>
> > One option/alternative I had been contemplating was making the tiles
> > plugin take the list of “tiles poms” and generate a realised/composed
> > pom as a fixed parent.
>
> This is exactly like the modelreader in maven 4 (previous polyglot
> extension) works, you can supply a file in an alternative format e.g.
> assume its called pom.tiles but even an xml with a different namespace
> should work and then you have to supply an (in memory) 'classic' model
> to maven see here:
>
>
> https://github.com/apache/maven/blob/master/compat/maven-model-builder/src/main/java/org/apache/maven/model/io/ModelReader.java
>
> in such a custom file format you can do whatever you want.
>
> Lets assume you do it that way and use an extended maven xsd for that it
> would probably be easier to discuss how/if this could be part of maven
> core as one can see what changes it really pulls in and what benefits it
> brings.
>
> Am 16.03.25 um 22:44 schrieb Mark Derricutt:
> > On 17 Mar 2025 at 3:04:31 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> >> And it just breaks all editors and IDE out there except the almost no
> more
> >> used netbeans ;)
> >>
> >
> > Does it? I guess that depends on how you use your IDE. IntelliJ still
> > resolves dependencies fine, and that’s all I care about— anything
> > maven/build/release I do at the command line.
> >
> > If one were to use tiles to include dependencies (which are considered
> > small and need to be enabled - I wish we’d never added support for that,
> > though it can be handy), IDEs can get confused, especially those that
> run a
> > single instance of Maven for the lifetime of the IDE. However, I find
> that
> > sometimes this causes problems regardless of using tiles.
> >
> > One option/alternative I had been contemplating was making the tiles
> plugin
> > take the list of “tiles poms” and generate a realised/composed pom as a
> > fixed parent.
> >
> > That would solve a bunch of things as it would just be
> >
> > a) generation of blended/decomposed XML
> > b) a released parent pom in your nexus/local repository
> >
> > To work effectively with Maven, it may be beneficial to utilize its APIs
> to
> > modify and create an “effective parent” during the build process.
> >
> > Mark
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
>> And it just breaks all editors and IDE out there except the almost no
>> more used netbeans ;)
>
> Does it?
At least m2e should work with tiles extension (basically with any
extension).
> One option/alternative I had been contemplating was making the tiles
> plugin take the list of “tiles poms” and generate a realised/composed
> pom as a fixed parent.
This is exactly like the modelreader in maven 4 (previous polyglot
extension) works, you can supply a file in an alternative format e.g.
assume its called pom.tiles but even an xml with a different namespace
should work and then you have to supply an (in memory) 'classic' model
to maven see here:
https://github.com/apache/maven/blob/master/compat/maven-model-builder/src/main/java/org/apache/maven/model/io/ModelReader.java
in such a custom file format you can do whatever you want.
Lets assume you do it that way and use an extended maven xsd for that it
would probably be easier to discuss how/if this could be part of maven
core as one can see what changes it really pulls in and what benefits it
brings.
Am 16.03.25 um 22:44 schrieb Mark Derricutt:
> On 17 Mar 2025 at 3:04:31 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> And it just breaks all editors and IDE out there except the almost no more
>> used netbeans ;)
>>
>
> Does it? I guess that depends on how you use your IDE. IntelliJ still
> resolves dependencies fine, and that’s all I care about— anything
> maven/build/release I do at the command line.
>
> If one were to use tiles to include dependencies (which are considered
> small and need to be enabled - I wish we’d never added support for that,
> though it can be handy), IDEs can get confused, especially those that run a
> single instance of Maven for the lifetime of the IDE. However, I find that
> sometimes this causes problems regardless of using tiles.
>
> One option/alternative I had been contemplating was making the tiles plugin
> take the list of “tiles poms” and generate a realised/composed pom as a
> fixed parent.
>
> That would solve a bunch of things as it would just be
>
> a) generation of blended/decomposed XML
> b) a released parent pom in your nexus/local repository
>
> To work effectively with Maven, it may be beneficial to utilize its APIs to
> modify and create an “effective parent” during the build process.
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 16 mars 2025 à 22:44, Mark Derricutt <ma...@talios.com> a écrit :
> On 17 Mar 2025 at 3:04:31 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > And it just breaks all editors and IDE out there except the almost no
> more
> > used netbeans ;)
> >
>
> Does it? I guess that depends on how you use your IDE. IntelliJ still
> resolves dependencies fine, and that’s all I care about— anything
> maven/build/release I do at the command line.
>
Yep, and I'm using idea but maven build doesn't just define dependencies.
Concretely it means you have to use the command line to do anything,
including running tests which is an impacting regression for end users.
The fact the IDE parses surefire (and it is a simple example) breaks easily.
It is the same for properties for ex.
>
> If one were to use tiles to include dependencies (which are considered
> small and need to be enabled - I wish we’d never added support for that,
> though it can be handy), IDEs can get confused, especially those that run a
> single instance of Maven for the lifetime of the IDE. However, I find that
> sometimes this causes problems regardless of using tiles.
>
> One option/alternative I had been contemplating was making the tiles plugin
> take the list of “tiles poms” and generate a realised/composed pom as a
> fixed parent.
>
> That would solve a bunch of things as it would just be
>
> a) generation of blended/decomposed XML
> b) a released parent pom in your nexus/local repository
>
> To work effectively with Maven, it may be beneficial to utilize its APIs to
> modify and create an “effective parent” during the build process.
>
AFAIK it exists using extensions so if you have some concrete issues after
v4 migration we can tackle them IMHO.
Will be better than today but will not be worse.
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
Re: What is new in Maven 4?
Posted by Mark Derricutt <ma...@talios.com>.
On 17 Mar 2025 at 3:04:31 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> And it just breaks all editors and IDE out there except the almost no more
> used netbeans ;)
>
Does it? I guess that depends on how you use your IDE. IntelliJ still
resolves dependencies fine, and that’s all I care about— anything
maven/build/release I do at the command line.
If one were to use tiles to include dependencies (which are considered
small and need to be enabled - I wish we’d never added support for that,
though it can be handy), IDEs can get confused, especially those that run a
single instance of Maven for the lifetime of the IDE. However, I find that
sometimes this causes problems regardless of using tiles.
One option/alternative I had been contemplating was making the tiles plugin
take the list of “tiles poms” and generate a realised/composed pom as a
fixed parent.
That would solve a bunch of things as it would just be
a) generation of blended/decomposed XML
b) a released parent pom in your nexus/local repository
To work effectively with Maven, it may be beneficial to utilize its APIs to
modify and create an “effective parent” during the build process.
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
Re: What is new in Maven 4?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
And it just breaks all editors and IDE out there except the almost no more
used netbeans ;) (it is often the limitations of such "preprocessor of
build file" tools, whatever way it is done technically - embed or literally
before the build).
So it will be hard to convince people to use vi to do java today.
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:57, Fred Cooke <fr...@gmail.com> a écrit :
> It's composition, most builds should be simple, and with tiles the poms are
> always small and succinct - just one plugin def, a unique GAV, 1 or more
> tiles in that plugin def, and the parent to satisfy maven, but the parent
> is empty and contributes precisely nothing (and exactly nothing so that
> everything comes from tiles).
>
> I guess you'd have to see it to believe it.
>
> On Mon, 17 Mar 2025 at 02:50, Romain Manni-Bucau <rm...@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 <el...@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 <fr...@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 <
> > elharo@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 <fr...@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 <
> > > elharo@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 <
> > > gnodet@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 <
> > > > > elharo@ibiblio.org>
> > > > > > > a
> > > > > > > > écrit :
> > > > > > > >
> > > > > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <
> > > mark@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
> > > > > > > > > elharo@ibiblio.org
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > ------------------------
> > > > > > > > Guillaume Nodet
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Elliotte Rusty Harold
> > > > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: What is new in Maven 4?
Posted by Fred Cooke <fr...@gmail.com>.
It's composition, most builds should be simple, and with tiles the poms are
always small and succinct - just one plugin def, a unique GAV, 1 or more
tiles in that plugin def, and the parent to satisfy maven, but the parent
is empty and contributes precisely nothing (and exactly nothing so that
everything comes from tiles).
I guess you'd have to see it to believe it.
On Mon, 17 Mar 2025 at 02:50, Romain Manni-Bucau <rm...@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 <el...@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 <fr...@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 <
> elharo@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 <fr...@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 <
> > elharo@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 <
> > gnodet@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 <
> > > > elharo@ibiblio.org>
> > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <
> > mark@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
> > > > > > > > elharo@ibiblio.org
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ------------------------
> > > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Elliotte Rusty Harold
> > > > > > elharo@ibiblio.org
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: What is new in Maven 4?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@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 <el...@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 <fr...@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 <el...@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 <fr...@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 <
> elharo@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 <
> gnodet@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 <
> > > elharo@ibiblio.org>
> > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <
> mark@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
> > > > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is new in Maven 4?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
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 <fr...@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 <el...@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 <fr...@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 <el...@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 <gn...@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 <
> > elharo@ibiblio.org>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
> > > > > > elharo@ibiblio.org
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Mark Derricutt <ma...@talios.com>.
On 17 Mar 2025 at 2:27:47 AM, Fred Cooke <fr...@gmail.com> wrote:
> Why not simply adopt the existing widely used tile system - but not require
> the plugin anymore
>
There are many reasons for that - at least in its current incarnation
(groovy based, tho I have a Java port but that also integrates some
questionable changes I did at the time).
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
Re: What is new in Maven 4?
Posted by Fred Cooke <fr...@gmail.com>.
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 <el...@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 <fr...@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 <el...@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 <gn...@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 <
> elharo@ibiblio.org>
> > > a
> > > > écrit :
> > > >
> > > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is new in Maven 4?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
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 <fr...@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 <el...@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 <gn...@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 <el...@ibiblio.org>
> > a
> > > écrit :
> > >
> > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
There was a discussion around mixins which happened years ago. I actually
implemented a POC 18 months ago:
https://github.com/apache/maven/pull/1209
Coupled with XInclude, which works quite well imho, despite what some seem
to indicate, I think it can already support a bunch of use cases.
I'd be also very happy to provide the needed API hooks to support tiles use
cases. The goal with the immutable model was not to forbid such things,
but rather to open the API at specific points so that Maven can support
them better at the end.
But supporting that in Maven can be done in 4.1 very easily. And it won't
break the whole ecosystem. The build/consumer POM feature allows hiding
changes in the build POM. So we can very easily add mixins support because
they would be inlined and translated into the consumer POM when reaching
the repository.
Le dim. 16 mars 2025 à 09:42, Fred Cooke <fr...@gmail.com> a écrit :
> 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 <el...@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 <gn...@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 <
> elharo@ibiblio.org>
> > a
> > > écrit :
> > >
> > > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Mark Derricutt <ma...@talios.com>.
Hey Fred,
I’d also love to revive the discussion, as it stands sadly - it seems Tiles
as a plugin is at an empass, it’s been awhile since I had a look at my
branch trying to update the code to M4 (had some personal health issues,
and work deadlines take me away from that tho).
With Maven 4’s move to being an immutable model, some of the nasty hacks we
had done are no longer workable, or at least, that I can see.
I’d love to see the functionality, at least the core functionality become a
standard feature in Maven, even V4 (which I believe it close to release) or
a 4.1 enhancement maybe.
I wonder if, as part of the new separation of build/consumer pom - some
form of inlining/merging of poms could be accomplished, with the build pom
referencing tiles/pom GAVs, which get transcluded into the consumer pom.
A while back I was considering something along the lines of how Polyglot
Maven has an XML dialect that gets processed instead of the current one, or
the Hocon extension:
https://github.com/apache/maven-hocon-extension
This new Hocon extension provides an Apache-supported vibe to the existing
pluggable model readers and writers, which appear to be one of those
mysterious areas of Maven that not many people are aware of.
I wonder if something there could be used to pull in modular poms - and
could be developed independently of future Maven 4.x releases.
Cheers for the support of Tiles as well!
Mark
On 16 Mar 2025 at 9:39:34 PM, Fred Cooke <fr...@gmail.com> wrote:
>
> 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.
>
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
Re: What is new in Maven 4?
Posted by Fred Cooke <fr...@gmail.com>.
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 <el...@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 <gn...@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 <el...@ibiblio.org>
> a
> > écrit :
> >
> > > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is new in Maven 4?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
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 <gn...@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 <el...@ibiblio.org> a
> écrit :
>
> > On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
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 <el...@ibiblio.org> a
écrit :
> On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Thu, Jan 23, 2025 at 12:16 AM Mark Derricutt <ma...@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
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Mark Derricutt <ma...@talios.com>.
On 23 Jan 2025 at 12:28:55 PM, Guillaume Nodet <gn...@apache.org> wrote:
> I did an experiment some time ago:
> https://github.com/apache/maven/pull/1209
>
Ahh - I didn’t think to look at PRs!
This would need to be rewritten.
> We also have https://github.com/apache/maven-xinclude-extension which is
> slightly related.
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).
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
Re: What is new in Maven 4?
Posted by Tamás Cservenák <ta...@cservenak.net>.
You sneaky.... :)
Yes, they will be able to run in parallel, but not yet, not in 4.0.x, a bit
patience pls :)
Thanks
T
On Thu, Jan 23, 2025, 15:21 Abel Salgado Romero <ab...@gmail.com>
wrote:
> Congratz everyone, great job!
>
> I saw the slides and these 2 comments:
>
> * Lifecycle changed from list to tree (branch out! 🌳)
> * Pre- and post-phase improvements (before: & after:! ↔️)
>
> ...they make me wonder:
> 1. What will be the behavior when multiple plugins attach to the same
> phase? Will there be some way to force certain order?
> 2. Lifecycle as a tree, means branches can run in parallel.
>
>
> On Thu, Jan 23, 2025 at 12:30 AM Guillaume Nodet <gn...@apache.org>
> wrote:
>
> > Le mer. 22 janv. 2025 à 23:32, Mark Derricutt <ma...@talios.com> a écrit
> :
> >
> > > Did any form of mixin’s make it’s way into Maven 4 at all? Looking at
> > all
> > > that new dependency inference looks cool, but didn’t see anything
> > > mentioning plugins?
> > >
> > > I remember seeing a <mixin> element mentioned somewhere in an IT test
> > some
> > > time ago but can’t for the life of me find it now, or any thing
> referring
> > > to it.
> > >
> >
> > I did an experiment some time ago:
> > https://github.com/apache/maven/pull/1209
> > This would need to be rewritten.
> > We also have https://github.com/apache/maven-xinclude-extension which is
> > slightly related.
> >
> >
> > >
> > > “multi parent” would be kinda nice. Having briefly looked at moving
> > tiles
> > > to M4 and hitting all the immutuble model classes (even tho there also
> > > private, and we’re hacking into that, major yuckville) it’d be great to
> > be
> > > able to just “retire” tiles in favor of M4.
> > >
> >
> > We're open to creating new SPI for needed use cases. Not sure where the
> > best
> > integration point would be, but if we can integrate cleanly, it may be
> > better.
> >
> > Guillaume
> >
> >
> > >
> > > Mark
> > >
> > > --
> > > "Great artists are extremely selfish and arrogant things" — Steven
> > Wilson,
> > > Porcupine Tree
> > >
> > >
> > > On 23 Jan 2025 at 4:25:02 AM, Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> > >
> > > > Howdy,
> > > >
> > > > Lately, we get this question quite often.
> > > >
> > > > Today Guillaume assembled this very informative presentation:
> > > > https://gnodet.github.io/maven4-presentation/
> > > >
> > > > There is also ongoing effort to assemble a page on Maven site as
> well:
> > > > https://github.com/apache/maven-site/pull/598
> > > >
> > > > Have fun
> > > > T
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
Re: What is new in Maven 4?
Posted by Abel Salgado Romero <ab...@gmail.com>.
Maybe. I have had issues in the past when multiple plugins run in the same
phase, so I'm not sure this addresses this.
Are there some docs? Googling brings some talks, I'll have to check them
closer, but it takes much more time than a written text .
On Fri, Jan 24, 2025 at 11:51 PM Nick Stolwijk <ni...@gmail.com>
wrote:
> Hi Abel
>
> On Thu, 23 Jan 2025 at 15:21, Abel Salgado Romero <ab...@gmail.com>
> wrote:
>
> > ...
> > * Pre- and post-phase improvements (before: & after:! ↔️)
> >
> > ...they make me wonder:
> > 1. What will be the behavior when multiple plugins attach to the same
> > phase? Will there be some way to force certain order?
> >
> Do you mean:
> > Fine-grained phase ordering, e.g., before:compile[10], validate[20]
> (perfect timing! ⏱️)
>
> That is in the presentation (Slide 10).
>
> With regards,
>
> Nick
>
Re: What is new in Maven 4?
Posted by Nick Stolwijk <ni...@gmail.com>.
Hi Abel
On Thu, 23 Jan 2025 at 15:21, Abel Salgado Romero <ab...@gmail.com>
wrote:
> ...
> * Pre- and post-phase improvements (before: & after:! ↔️)
>
> ...they make me wonder:
> 1. What will be the behavior when multiple plugins attach to the same
> phase? Will there be some way to force certain order?
>
Do you mean:
> Fine-grained phase ordering, e.g., before:compile[10], validate[20]
(perfect timing! ⏱️)
That is in the presentation (Slide 10).
With regards,
Nick
Re: What is new in Maven 4?
Posted by Tamás Cservenák <ta...@cservenak.net>.
You sneaky.... :)
Yes, they will be able to run in parallel, but not yet, not in 4.0.x, a bit
patience pls :)
Thanks
T
On Thu, Jan 23, 2025, 15:21 Abel Salgado Romero <ab...@gmail.com>
wrote:
> Congratz everyone, great job!
>
> I saw the slides and these 2 comments:
>
> * Lifecycle changed from list to tree (branch out! 🌳)
> * Pre- and post-phase improvements (before: & after:! ↔️)
>
> ...they make me wonder:
> 1. What will be the behavior when multiple plugins attach to the same
> phase? Will there be some way to force certain order?
> 2. Lifecycle as a tree, means branches can run in parallel.
>
>
> On Thu, Jan 23, 2025 at 12:30 AM Guillaume Nodet <gn...@apache.org>
> wrote:
>
> > Le mer. 22 janv. 2025 à 23:32, Mark Derricutt <ma...@talios.com> a écrit
> :
> >
> > > Did any form of mixin’s make it’s way into Maven 4 at all? Looking at
> > all
> > > that new dependency inference looks cool, but didn’t see anything
> > > mentioning plugins?
> > >
> > > I remember seeing a <mixin> element mentioned somewhere in an IT test
> > some
> > > time ago but can’t for the life of me find it now, or any thing
> referring
> > > to it.
> > >
> >
> > I did an experiment some time ago:
> > https://github.com/apache/maven/pull/1209
> > This would need to be rewritten.
> > We also have https://github.com/apache/maven-xinclude-extension which is
> > slightly related.
> >
> >
> > >
> > > “multi parent” would be kinda nice. Having briefly looked at moving
> > tiles
> > > to M4 and hitting all the immutuble model classes (even tho there also
> > > private, and we’re hacking into that, major yuckville) it’d be great to
> > be
> > > able to just “retire” tiles in favor of M4.
> > >
> >
> > We're open to creating new SPI for needed use cases. Not sure where the
> > best
> > integration point would be, but if we can integrate cleanly, it may be
> > better.
> >
> > Guillaume
> >
> >
> > >
> > > Mark
> > >
> > > --
> > > "Great artists are extremely selfish and arrogant things" — Steven
> > Wilson,
> > > Porcupine Tree
> > >
> > >
> > > On 23 Jan 2025 at 4:25:02 AM, Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> > >
> > > > Howdy,
> > > >
> > > > Lately, we get this question quite often.
> > > >
> > > > Today Guillaume assembled this very informative presentation:
> > > > https://gnodet.github.io/maven4-presentation/
> > > >
> > > > There is also ongoing effort to assemble a page on Maven site as
> well:
> > > > https://github.com/apache/maven-site/pull/598
> > > >
> > > > Have fun
> > > > T
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
Re: What is new in Maven 4?
Posted by Abel Salgado Romero <ab...@gmail.com>.
Congratz everyone, great job!
I saw the slides and these 2 comments:
* Lifecycle changed from list to tree (branch out! 🌳)
* Pre- and post-phase improvements (before: & after:! ↔️)
...they make me wonder:
1. What will be the behavior when multiple plugins attach to the same
phase? Will there be some way to force certain order?
2. Lifecycle as a tree, means branches can run in parallel.
On Thu, Jan 23, 2025 at 12:30 AM Guillaume Nodet <gn...@apache.org> wrote:
> Le mer. 22 janv. 2025 à 23:32, Mark Derricutt <ma...@talios.com> a écrit :
>
> > Did any form of mixin’s make it’s way into Maven 4 at all? Looking at
> all
> > that new dependency inference looks cool, but didn’t see anything
> > mentioning plugins?
> >
> > I remember seeing a <mixin> element mentioned somewhere in an IT test
> some
> > time ago but can’t for the life of me find it now, or any thing referring
> > to it.
> >
>
> I did an experiment some time ago:
> https://github.com/apache/maven/pull/1209
> This would need to be rewritten.
> We also have https://github.com/apache/maven-xinclude-extension which is
> slightly related.
>
>
> >
> > “multi parent” would be kinda nice. Having briefly looked at moving
> tiles
> > to M4 and hitting all the immutuble model classes (even tho there also
> > private, and we’re hacking into that, major yuckville) it’d be great to
> be
> > able to just “retire” tiles in favor of M4.
> >
>
> We're open to creating new SPI for needed use cases. Not sure where the
> best
> integration point would be, but if we can integrate cleanly, it may be
> better.
>
> Guillaume
>
>
> >
> > Mark
> >
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> > Porcupine Tree
> >
> >
> > On 23 Jan 2025 at 4:25:02 AM, Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >
> > > Howdy,
> > >
> > > Lately, we get this question quite often.
> > >
> > > Today Guillaume assembled this very informative presentation:
> > > https://gnodet.github.io/maven4-presentation/
> > >
> > > There is also ongoing effort to assemble a page on Maven site as well:
> > > https://github.com/apache/maven-site/pull/598
> > >
> > > Have fun
> > > T
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 22 janv. 2025 à 23:32, Mark Derricutt <ma...@talios.com> a écrit :
> Did any form of mixin’s make it’s way into Maven 4 at all? Looking at all
> that new dependency inference looks cool, but didn’t see anything
> mentioning plugins?
>
> I remember seeing a <mixin> element mentioned somewhere in an IT test some
> time ago but can’t for the life of me find it now, or any thing referring
> to it.
>
I did an experiment some time ago:
https://github.com/apache/maven/pull/1209
This would need to be rewritten.
We also have https://github.com/apache/maven-xinclude-extension which is
slightly related.
>
> “multi parent” would be kinda nice. Having briefly looked at moving tiles
> to M4 and hitting all the immutuble model classes (even tho there also
> private, and we’re hacking into that, major yuckville) it’d be great to be
> able to just “retire” tiles in favor of M4.
>
We're open to creating new SPI for needed use cases. Not sure where the
best
integration point would be, but if we can integrate cleanly, it may be
better.
Guillaume
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On 23 Jan 2025 at 4:25:02 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
>
> > Howdy,
> >
> > Lately, we get this question quite often.
> >
> > Today Guillaume assembled this very informative presentation:
> > https://gnodet.github.io/maven4-presentation/
> >
> > There is also ongoing effort to assemble a page on Maven site as well:
> > https://github.com/apache/maven-site/pull/598
> >
> > Have fun
> > T
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 22 janv. 2025 à 23:32, Mark Derricutt <ma...@talios.com> a écrit :
> Did any form of mixin’s make it’s way into Maven 4 at all? Looking at all
> that new dependency inference looks cool, but didn’t see anything
> mentioning plugins?
>
> I remember seeing a <mixin> element mentioned somewhere in an IT test some
> time ago but can’t for the life of me find it now, or any thing referring
> to it.
>
I did an experiment some time ago:
https://github.com/apache/maven/pull/1209
This would need to be rewritten.
We also have https://github.com/apache/maven-xinclude-extension which is
slightly related.
>
> “multi parent” would be kinda nice. Having briefly looked at moving tiles
> to M4 and hitting all the immutuble model classes (even tho there also
> private, and we’re hacking into that, major yuckville) it’d be great to be
> able to just “retire” tiles in favor of M4.
>
We're open to creating new SPI for needed use cases. Not sure where the
best
integration point would be, but if we can integrate cleanly, it may be
better.
Guillaume
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On 23 Jan 2025 at 4:25:02 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
>
> > Howdy,
> >
> > Lately, we get this question quite often.
> >
> > Today Guillaume assembled this very informative presentation:
> > https://gnodet.github.io/maven4-presentation/
> >
> > There is also ongoing effort to assemble a page on Maven site as well:
> > https://github.com/apache/maven-site/pull/598
> >
> > Have fun
> > T
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Mark Derricutt <ma...@talios.com>.
Did any form of mixin’s make it’s way into Maven 4 at all? Looking at all
that new dependency inference looks cool, but didn’t see anything
mentioning plugins?
I remember seeing a <mixin> element mentioned somewhere in an IT test some
time ago but can’t for the life of me find it now, or any thing referring
to it.
“multi parent” would be kinda nice. Having briefly looked at moving tiles
to M4 and hitting all the immutuble model classes (even tho there also
private, and we’re hacking into that, major yuckville) it’d be great to be
able to just “retire” tiles in favor of M4.
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On 23 Jan 2025 at 4:25:02 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
> Howdy,
>
> Lately, we get this question quite often.
>
> Today Guillaume assembled this very informative presentation:
> https://gnodet.github.io/maven4-presentation/
>
> There is also ongoing effort to assemble a page on Maven site as well:
> https://github.com/apache/maven-site/pull/598
>
> Have fun
> T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: What is new in Maven 4?
Posted by Mark Raynsford <or...@io7m.com>.
On 24/01/2025 13:47, Guillaume Nodet wrote:
> Le ven. 24 janv. 2025 à 11:25, Mark Raynsford <
>> Are there details somewhere on the dependency "inference"?
>>
>
> This goes back to https://issues.apache.org/jira/browse/MNG-6656
> To summarize (and it has changed since the original commit), if your pom
> uses model 4.1.0, for each dependency that has no version directly
> specified,
> Maven will look in the whole project (from the root project and all child
> subprojects)
> for a matching groupId:artifactId. If there's only one, it will use that
> version.
> So you don't have to manage that version in the root pom as it's usually
> done.
> The groupId can also be inferred, so you can only specify the artifactId.
Sounds like it'll be useful for cutting out a lot of this kind of thing:
https://github.com/io7m-com/cedarbridge/blob/539d68ba110157c4822d9802cdce200cca507488/com.io7m.cedarbridge.tests/pom.xml#L31
It's a "tests" module that has a dependency on all of the other modules
within the project.
--
Mark Raynsford | https://www.io7m.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
Give "gh" a try, it really helps dealing with github repos and PRs.
Checking out a PR is "gh pr checkout 2060", no need to add a remote repo or
whatever...
Le ven. 24 janv. 2025 à 14:54, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> Perhaps. I use git.
>
> On Fri, Jan 24, 2025 at 1:47 PM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > Le ven. 24 janv. 2025 à 11:25, Mark Raynsford <
> > org.apache.maven.user@io7m.com> a écrit :
> >
> > > On 22/01/2025 15:25, Tamás Cservenák wrote:
> > > > Howdy,
> > > >
> > > > Lately, we get this question quite often.
> > > >
> > > > Today Guillaume assembled this very informative presentation:
> > > > https://gnodet.github.io/maven4-presentation/
> > > >
> > > > There is also ongoing effort to assemble a page on Maven site as
> well:
> > > > https://github.com/apache/maven-site/pull/598
> > >
> > > Hello!
> > >
> > > Are there details somewhere on the dependency "inference"?
> > >
> >
> > This goes back to https://issues.apache.org/jira/browse/MNG-6656
> > To summarize (and it has changed since the original commit), if your pom
> > uses model 4.1.0, for each dependency that has no version directly
> > specified,
> > Maven will look in the whole project (from the root project and all child
> > subprojects)
> > for a matching groupId:artifactId. If there's only one, it will use that
> > version.
> > So you don't have to manage that version in the root pom as it's usually
> > done.
> > The groupId can also be inferred, so you can only specify the artifactId.
> >
> >
> > >
> > > --
> > > Mark Raynsford | https://www.io7m.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
Perhaps. I use git.
On Fri, Jan 24, 2025 at 1:47 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> Le ven. 24 janv. 2025 à 11:25, Mark Raynsford <
> org.apache.maven.user@io7m.com> a écrit :
>
> > On 22/01/2025 15:25, Tamás Cservenák wrote:
> > > Howdy,
> > >
> > > Lately, we get this question quite often.
> > >
> > > Today Guillaume assembled this very informative presentation:
> > > https://gnodet.github.io/maven4-presentation/
> > >
> > > There is also ongoing effort to assemble a page on Maven site as well:
> > > https://github.com/apache/maven-site/pull/598
> >
> > Hello!
> >
> > Are there details somewhere on the dependency "inference"?
> >
>
> This goes back to https://issues.apache.org/jira/browse/MNG-6656
> To summarize (and it has changed since the original commit), if your pom
> uses model 4.1.0, for each dependency that has no version directly
> specified,
> Maven will look in the whole project (from the root project and all child
> subprojects)
> for a matching groupId:artifactId. If there's only one, it will use that
> version.
> So you don't have to manage that version in the root pom as it's usually
> done.
> The groupId can also be inferred, so you can only specify the artifactId.
>
>
> >
> > --
> > Mark Raynsford | https://www.io7m.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
Le ven. 24 janv. 2025 à 11:25, Mark Raynsford <
org.apache.maven.user@io7m.com> a écrit :
> On 22/01/2025 15:25, Tamás Cservenák wrote:
> > Howdy,
> >
> > Lately, we get this question quite often.
> >
> > Today Guillaume assembled this very informative presentation:
> > https://gnodet.github.io/maven4-presentation/
> >
> > There is also ongoing effort to assemble a page on Maven site as well:
> > https://github.com/apache/maven-site/pull/598
>
> Hello!
>
> Are there details somewhere on the dependency "inference"?
>
This goes back to https://issues.apache.org/jira/browse/MNG-6656
To summarize (and it has changed since the original commit), if your pom
uses model 4.1.0, for each dependency that has no version directly
specified,
Maven will look in the whole project (from the root project and all child
subprojects)
for a matching groupId:artifactId. If there's only one, it will use that
version.
So you don't have to manage that version in the root pom as it's usually
done.
The groupId can also be inferred, so you can only specify the artifactId.
>
> --
> Mark Raynsford | https://www.io7m.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: What is new in Maven 4?
Posted by Mark Raynsford <or...@io7m.com>.
On 22/01/2025 15:25, Tamás Cservenák wrote:
> Howdy,
>
> Lately, we get this question quite often.
>
> Today Guillaume assembled this very informative presentation:
> https://gnodet.github.io/maven4-presentation/
>
> There is also ongoing effort to assemble a page on Maven site as well:
> https://github.com/apache/maven-site/pull/598
Hello!
Are there details somewhere on the dependency "inference"?
--
Mark Raynsford | https://www.io7m.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy Matthias,
over a month ago I told you to "just merge" (and continue
incrementally improving the page).
I am not a believer of "über PR" that should be cooked for weeks,
months until they are 100% (or 99.9999%).
Especially for a site, a page, that can just be incrementally improved
as Maven 4 dev is still ongoing.
If it were me, my first PR would just be an empty page with a title :)
So yes, just add the remark "in progress" and merge it.
T
On Sat, Feb 22, 2025 at 10:37 AM Matthias Bünger
<ru...@web.de.invalid> wrote:
>
> Good morning,
> over two months ago I created the PR about "What's new in Maven 4". It
> has been stale since about a month now and I feel a bit lost how to
> continue with it.
> During the PR discussion I created one follow up issue [1] to clearly
> define and describe top, root, and base directories, session and
> directory properties as it turned out that those are not clearly
> described in the documentation yet.
>
> On January 5th, Sylwester asked, if I want to release it now or wait
> until release of Maven 4. Aside from the follow up mentioned before, I
> do think the page is good to serve people who are interesting what will
> change. That was the starting point for the PR, based on a Slack message
> by Tamas, asking if someone can write the changes down. Also the talks I
> give on that topic have a lot of listeners. However, from comments in
> other discussions I got the _feeling_ (I don't know if this is true)
> that some don't want to publish Maven 4 things, until Maven 4 final
> version is released.
>
> So I was thinking about how to move on with the PR: Shall I add a note
> at the start of the article clearly mentioned that current state is RC2
> and the article will get updated (at least) until Maven 4.0.0 is
> released? Would this okay for all to get this (really large) PR done?
>
> Matthias
>
>
> [1] https://github.com/apache/maven-site/issues/651
>
> Am 22.01.2025 um 16:25 schrieb Tamás Cservenák:
> > Howdy,
> >
> > Lately, we get this question quite often.
> >
> > Today Guillaume assembled this very informative presentation:
> > https://gnodet.github.io/maven4-presentation/
> >
> > There is also ongoing effort to assemble a page on Maven site as well:
> > https://github.com/apache/maven-site/pull/598
> >
> > Have fun
> > T
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Matthias Bünger <ru...@web.de.INVALID>.
Good morning,
over two months ago I created the PR about "What's new in Maven 4". It
has been stale since about a month now and I feel a bit lost how to
continue with it.
During the PR discussion I created one follow up issue [1] to clearly
define and describe top, root, and base directories, session and
directory properties as it turned out that those are not clearly
described in the documentation yet.
On January 5th, Sylwester asked, if I want to release it now or wait
until release of Maven 4. Aside from the follow up mentioned before, I
do think the page is good to serve people who are interesting what will
change. That was the starting point for the PR, based on a Slack message
by Tamas, asking if someone can write the changes down. Also the talks I
give on that topic have a lot of listeners. However, from comments in
other discussions I got the _feeling_ (I don't know if this is true)
that some don't want to publish Maven 4 things, until Maven 4 final
version is released.
So I was thinking about how to move on with the PR: Shall I add a note
at the start of the article clearly mentioned that current state is RC2
and the article will get updated (at least) until Maven 4.0.0 is
released? Would this okay for all to get this (really large) PR done?
Matthias
[1] https://github.com/apache/maven-site/issues/651
Am 22.01.2025 um 16:25 schrieb Tamás Cservenák:
> Howdy,
>
> Lately, we get this question quite often.
>
> Today Guillaume assembled this very informative presentation:
> https://gnodet.github.io/maven4-presentation/
>
> There is also ongoing effort to assemble a page on Maven site as well:
> https://github.com/apache/maven-site/pull/598
>
> Have fun
> T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Guillaume Nodet <gn...@apache.org>.
Another point to consider is that the new inference mechanism mostly
fulfills the need to import your own BOM.
------------------------
Guillaume Nodet
Le sam. 25 janv. 2025 à 02:11, Tamás Cservenák <ta...@cservenak.net> a
écrit :
> Howdy,
>
> The story of BOM POMs is manifold.
> BOM POMs are a "very good thing" to publish for _downstream consumers_
> that consume your stack.
> Problems begin when devs try to "reuse" the BOM within their own build
> (same reactor BOM is published from).
>
> If consuming BOM, it should ideally come from outside (external to)
> your reactor.
> If you use "import" scope within the reactor, it is where (does not
> have to, IF you are VERY careful) problems begin.
> Moreover, you usually want to "detach" the BOM from your parent POM,
> that even more introduce peculiarities and problems
> (ie. how to deploy it? So you now introduce some "skinny" parent, etc)
>
> Hence, the general rule of thumb is:
> - BOM is good per se
> - BOMs you consume should _always_ originate from outside of the
> reactor (simply to avoid all the problems).
> - BOMs you produce should target downstream consumers ONLY
>
> Moreover, Maven 4 has a capability now (not in Maven3!) to _import BOM
> with classifier_.
>
> Hence, with Maven4 (obviously, this makes build maven4 only), the
> preferred way to do things is:
> - sort out dependencies in reactor "as usual", using INHERITANCE
> - do NOT re-import BOM within reactor
> - BOM you author/publish should be used ONLY by downstream projects
> - generate your BOM
>
> As an example, you can look at Maven build itself:
> - it generates BOM
> - offers two BOMs: skinny and fat
>
> And here comes the second important bit: there is a disagreement (or
> different interpretation) about "what BOM is".
> Hence, Maven itself delivers TWO BOMs: skinny and fat. See [1] for
> explaining what "skinny" and "fat" BOMs are.
>
> [1] https://github.com/apache/maven-site/pull/598#discussion_r1894013277
>
> HTH
> T
>
> On Sat, Jan 25, 2025 at 1:50 AM Olivier Lamy <ol...@apache.org> wrote:
> >
> > Hi,
> > Nice presentation.
> > I have been asking on slack but no answer, so I still don't understand
> why this
> > " Warning: Same-reactor BOMs will be deprecated (use external BOMs
> only!` ?"
> >
> > It's very convenient for large projects providing boms to have
> > demos/examples as part of their build.
> > And obviously, those demos/examples use the bombs to show good usage
> > (in my case, the Jetty project).
> > So why is it such a problem?
> >
> > On Thu, 23 Jan 2025 at 01:25, Tamás Cservenák <ta...@cservenak.net>
> wrote:
> > >
> > > Howdy,
> > >
> > > Lately, we get this question quite often.
> > >
> > > Today Guillaume assembled this very informative presentation:
> > > https://gnodet.github.io/maven4-presentation/
> > >
> > > There is also ongoing effort to assemble a page on Maven site as well:
> > > https://github.com/apache/maven-site/pull/598
> > >
> > > Have fun
> > > T
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What is new in Maven 4?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy, just a short pointer to published BOMs:
https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/4.0.0-rc-2/
Here you can inspect generated "fat" and "skinny" BOMs Maven4 build produces.
T
On Sat, Jan 25, 2025 at 2:10 AM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Howdy,
>
> The story of BOM POMs is manifold.
> BOM POMs are a "very good thing" to publish for _downstream consumers_
> that consume your stack.
> Problems begin when devs try to "reuse" the BOM within their own build
> (same reactor BOM is published from).
>
> If consuming BOM, it should ideally come from outside (external to)
> your reactor.
> If you use "import" scope within the reactor, it is where (does not
> have to, IF you are VERY careful) problems begin.
> Moreover, you usually want to "detach" the BOM from your parent POM,
> that even more introduce peculiarities and problems
> (ie. how to deploy it? So you now introduce some "skinny" parent, etc)
>
> Hence, the general rule of thumb is:
> - BOM is good per se
> - BOMs you consume should _always_ originate from outside of the
> reactor (simply to avoid all the problems).
> - BOMs you produce should target downstream consumers ONLY
>
> Moreover, Maven 4 has a capability now (not in Maven3!) to _import BOM
> with classifier_.
>
> Hence, with Maven4 (obviously, this makes build maven4 only), the
> preferred way to do things is:
> - sort out dependencies in reactor "as usual", using INHERITANCE
> - do NOT re-import BOM within reactor
> - BOM you author/publish should be used ONLY by downstream projects
> - generate your BOM
>
> As an example, you can look at Maven build itself:
> - it generates BOM
> - offers two BOMs: skinny and fat
>
> And here comes the second important bit: there is a disagreement (or
> different interpretation) about "what BOM is".
> Hence, Maven itself delivers TWO BOMs: skinny and fat. See [1] for
> explaining what "skinny" and "fat" BOMs are.
>
> [1] https://github.com/apache/maven-site/pull/598#discussion_r1894013277
>
> HTH
> T
>
> On Sat, Jan 25, 2025 at 1:50 AM Olivier Lamy <ol...@apache.org> wrote:
> >
> > Hi,
> > Nice presentation.
> > I have been asking on slack but no answer, so I still don't understand why this
> > " Warning: Same-reactor BOMs will be deprecated (use external BOMs only!` ?"
> >
> > It's very convenient for large projects providing boms to have
> > demos/examples as part of their build.
> > And obviously, those demos/examples use the bombs to show good usage
> > (in my case, the Jetty project).
> > So why is it such a problem?
> >
> > On Thu, 23 Jan 2025 at 01:25, Tamás Cservenák <ta...@cservenak.net> wrote:
> > >
> > > Howdy,
> > >
> > > Lately, we get this question quite often.
> > >
> > > Today Guillaume assembled this very informative presentation:
> > > https://gnodet.github.io/maven4-presentation/
> > >
> > > There is also ongoing effort to assemble a page on Maven site as well:
> > > https://github.com/apache/maven-site/pull/598
> > >
> > > Have fun
> > > T
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
The story of BOM POMs is manifold.
BOM POMs are a "very good thing" to publish for _downstream consumers_
that consume your stack.
Problems begin when devs try to "reuse" the BOM within their own build
(same reactor BOM is published from).
If consuming BOM, it should ideally come from outside (external to)
your reactor.
If you use "import" scope within the reactor, it is where (does not
have to, IF you are VERY careful) problems begin.
Moreover, you usually want to "detach" the BOM from your parent POM,
that even more introduce peculiarities and problems
(ie. how to deploy it? So you now introduce some "skinny" parent, etc)
Hence, the general rule of thumb is:
- BOM is good per se
- BOMs you consume should _always_ originate from outside of the
reactor (simply to avoid all the problems).
- BOMs you produce should target downstream consumers ONLY
Moreover, Maven 4 has a capability now (not in Maven3!) to _import BOM
with classifier_.
Hence, with Maven4 (obviously, this makes build maven4 only), the
preferred way to do things is:
- sort out dependencies in reactor "as usual", using INHERITANCE
- do NOT re-import BOM within reactor
- BOM you author/publish should be used ONLY by downstream projects
- generate your BOM
As an example, you can look at Maven build itself:
- it generates BOM
- offers two BOMs: skinny and fat
And here comes the second important bit: there is a disagreement (or
different interpretation) about "what BOM is".
Hence, Maven itself delivers TWO BOMs: skinny and fat. See [1] for
explaining what "skinny" and "fat" BOMs are.
[1] https://github.com/apache/maven-site/pull/598#discussion_r1894013277
HTH
T
On Sat, Jan 25, 2025 at 1:50 AM Olivier Lamy <ol...@apache.org> wrote:
>
> Hi,
> Nice presentation.
> I have been asking on slack but no answer, so I still don't understand why this
> " Warning: Same-reactor BOMs will be deprecated (use external BOMs only!` ?"
>
> It's very convenient for large projects providing boms to have
> demos/examples as part of their build.
> And obviously, those demos/examples use the bombs to show good usage
> (in my case, the Jetty project).
> So why is it such a problem?
>
> On Thu, 23 Jan 2025 at 01:25, Tamás Cservenák <ta...@cservenak.net> wrote:
> >
> > Howdy,
> >
> > Lately, we get this question quite often.
> >
> > Today Guillaume assembled this very informative presentation:
> > https://gnodet.github.io/maven4-presentation/
> >
> > There is also ongoing effort to assemble a page on Maven site as well:
> > https://github.com/apache/maven-site/pull/598
> >
> > Have fun
> > T
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
Nice presentation.
I have been asking on slack but no answer, so I still don't understand why this
" Warning: Same-reactor BOMs will be deprecated (use external BOMs only!` ?"
It's very convenient for large projects providing boms to have
demos/examples as part of their build.
And obviously, those demos/examples use the bombs to show good usage
(in my case, the Jetty project).
So why is it such a problem?
On Thu, 23 Jan 2025 at 01:25, Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Howdy,
>
> Lately, we get this question quite often.
>
> Today Guillaume assembled this very informative presentation:
> https://gnodet.github.io/maven4-presentation/
>
> There is also ongoing effort to assemble a page on Maven site as well:
> https://github.com/apache/maven-site/pull/598
>
> Have fun
> T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is new in Maven 4?
Posted by Mark Derricutt <ma...@talios.com>.
Did any form of mixin’s make it’s way into Maven 4 at all? Looking at all
that new dependency inference looks cool, but didn’t see anything
mentioning plugins?
I remember seeing a <mixin> element mentioned somewhere in an IT test some
time ago but can’t for the life of me find it now, or any thing referring
to it.
“multi parent” would be kinda nice. Having briefly looked at moving tiles
to M4 and hitting all the immutuble model classes (even tho there also
private, and we’re hacking into that, major yuckville) it’d be great to be
able to just “retire” tiles in favor of M4.
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On 23 Jan 2025 at 4:25:02 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
> Howdy,
>
> Lately, we get this question quite often.
>
> Today Guillaume assembled this very informative presentation:
> https://gnodet.github.io/maven4-presentation/
>
> There is also ongoing effort to assemble a page on Maven site as well:
> https://github.com/apache/maven-site/pull/598
>
> Have fun
> T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>