Hi all,
I’d like to suggest we switch the master branch to 4.0.0-SNAPSHOT and
enable new features as “preview” options, guarded behind feature flags.
Maintaining the gap between master and 4.0.x has become increasingly
difficult, especially around tracking which changes have or haven’t been
backp
ter.
> >>>>
> >>>> Yes, having a single branch with new features in preview mode seems
> >> even
> >>>> better to me.
> >>>>
> >>>> Martin
> >>>>
> >>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
mannibucau.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-perfor
e such case, but still - the behaviour of inclusion
> depends on the effective profile, not the defined one.
>
> May be it would also make sense to restrict profiles declared in
> settings.xml and not allow such “global” profiles to include submodules,
> wdyt?
>
>
>
> >
ith absent tag
> and empty () one to disable scanning - in the same way it is
> done with ?
>
Unfortunately, we can't easily do that, as we can't have null lists in the
model (those are transformed into empty ones).
>
> Thanks, Alex
>
> > On 15 Sep 2025, at 3:11 PM,
ting Maven 3 projects.
But as I said, it's missing a verification that no profiles on this POM
defines a subproject/module.
THis is required in order to be able to activate some subprojects using
profiles, without having
any default subprojects when not using any specific profile.
>
>
&g
;
> Is it an expected behavior?
> ---
> Nikita Skvortsov
> Java Build Tools Team Lead
>
> JetBrains N.V. | KvK reg. nr. 56460279
> Gelrestraat 16, 1079 MZ Amsterdam, The Netherlands
> T: + 31 (0)20 205 01 18 | F: +31 (0)20 205 01 19
> E: nikita.skvort...@jetbrains.com
>
--
Guillaume Nodet
;> So for me less is more and disabling it in case it is not
> wanted
> > is
> > >> >> always a bit cumbersome. Then everyone can simply configure in
> > their
> > >> parent
> > >> >> pom whats wanted by default.
> > >> >>>>
> > >> >>>>> Am 05.09.25 um 07:56 schrieb Rüdiger:
> > >> >>>>> Hiho!
> > >> >>>>> I was wondering, what you all think about adding the failsafe
> > plugin
> > >> >> to the super pom of maven 4. I often work with young teams, and
> > it's
> > >> >> difficult to explain, why the surefire plugin works out of the
> box,
> > >> but the
> > >> >> failsafe plugin does not... and of course, it's a nuisance to
> have
> > >> to add
> > >> >> it to every project.
> > >> >>>>> Maybe unit tests used to be more important than integration
> > tests in
> > >> >> the past, but my perception is that this is changing: ITs become
> > >> more and
> > >> >> more the primary way of testing, while unit tests become more
> > >> optional and
> > >> >> focus on more complex algorithms.
> > >> >>>>> Kind regards
> > >> >>>>> Rüdiger
> > >> >>>>>
> > >> -
> > >> >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> >>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > -
> > >> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> >>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >> >>>>
> > >> >>>
> > >> >>>
> > >> >>>
> > -
> > >> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > -
> > >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >> >>
> > >> >>
> > >> >
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
--
Guillaume Nodet
gt; you
> > > >> want
> > > >>>> to lock plugin versions) but 2 is not 100% perfect since it can
> hide
> > > >> the
> > > >>>> fact you do use another version.
> > > >>>>
> > > >>>> However we are lucky and have enforcer plugin which does solves
> it.
> > > >>>>
> > > >>>> So I wonder if we should revert the version locking warning when
> pom
> > > is
> > > >>>> without any build section for default plugins.
> > > >>>>
> > > >>>> I know a custom extensions can somehow replace a super pom and
> kind of
> > > >>>> solve it but you still need to define it which is still undesired
> to
> > > >>> have a
> > > >>>> proper default "convention" setup 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
> > > >>>
> -
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >>> For additional commands, e-mail: dev-h...@maven.apache.org
> > > >>>
> > > >>>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
ant
> > >>>> to lock plugin versions) but 2 is not 100% perfect since it can hide
> > >> the
> > >>>> fact you do use another version.
> > >>>>
> > >>>> However we are lucky and have enforcer plugin which does solves it.
> > >>>>
> > >>>> So I wonder if we should revert the version locking warning when pom
> > is
> > >>>> without any build section for default plugins.
> > >>>>
> > >>>> I know a custom extensions can somehow replace a super pom and kind
> of
> > >>>> solve it but you still need to define it which is still undesired to
> > >>> have a
> > >>>> proper default "convention" setup 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
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>>
> > >>>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
--
Guillaume Nodet
e this?
>
> On Wed, Jul 23, 2025 at 8:46 PM Guillaume Nodet wrote:
>
> > Hi Maven team,
> >
> > I'd like to request a review for a new Maven Wrapper enhancement that
> adds
> > automatic JDK download capabilities.
> >
> > PR Details: https://g
d, and attackers looking to
> > compromise
> > > > > systems are often more devious than me. And again we don't actually
> > > > > gain anything useful by allowing multiple namespaces so locking
> this
> > > > > down feels prudent.
> > &g
ing manual JDK setup steps for teams that choose to
use it.
Looking forward to your feedback!
Best regards,
Guillaume Nodet
t all.
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
is acceptable
for a 4.x release?
3. *Long-term vision*: Would a properly planned Maven 5.0 namespace
overhaul better serve our goals?
I'm interested in hearing the community's thoughts on this timing vs.
technical merit trade-off.
Best regards,
Guillaume Nodet
-
at a coherent
> > > > message can
> > > > > > > > > be sent to the community ?
> > > > > > > > >
> > > > > > > > > Aggravating factors in central-publishing-maven-plugin that
> > > lead
> > > > to
> > > > > > > > > uncertainty according to me:
> > > > > > > > > - Similarity with the standard maven-deploy-plugin. Sonatype
> > > > even has
> > > > > > > > > a compatibility service but its use is discouraged ("We hope
> > > > that over
> > > > > > > > > time plugins will adopt the Portal API rather than rely on
> > this
> > > > > > > > > service" in
> > > > > > > > >
> > > > https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/
> > > > > > > > > ).
> > > > > > > > > - No public scm system available makes it hard to get context
> > > > > > > > > information (
> > > > > > > > >
> > > > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing
> > > > > > > > > -m
> > > > > > > > > a
> > > > > > > > > ven-plugin/0.8.0/central-publishing-maven-plugin-0.8.0.pom
> > > lists
> > > > > > > > > https://github.com/sonatype/central-publishing-maven-plugin
> > > but
> > > > is
> > > > > > > > > 404).
> > > > > > > > > (Note: The code is still available in the source jar
> > > > > > > > > alongside the plugin
> > > > > > > > >
> > > > https://repo1.maven.org/maven2/org/sonatype/central/central-publishing
> > > > > > > > > -m
> > > > > > > > > av
> > > > > > > > >
> > > > en-plugin/0.8.0/central-publishing-maven-plugin-0.8.0-sources.jar )
> > > > > > > > > - central-publishing-maven-plugin uses
> > > > true to
> > > > > > > > > forcefully remove any invocation of the maven-deploy-plugin
> > > > which I
> > > > > > > > > found surprising (aggressive ?) behavior.
> > > > > > > > > - impossible as of 0.8.0 to use
> > central-publishing-maven-plugin
> > > > behind
> > > > > > > > > a corporate proxy which ( by virtue of the http client5 of
> > > apache
> > > > > > > > > httpcomponents without the extra code required to allow
> > proxies
> > > > ...)
> > > > > > > > > - looks like fighting instead of cooperating (even though the
> > > > plugin
> > > > > > > > > architecture of maven invites this kind of work, maybe it's
> > > > better
> > > > > > > > > when core functionality stays within the maven umbrella like
> > > the
> > > > > > > > > maven-deploy-plugin?)
> > > > > > > > >
> > > > > > > > > What are your thoughts ? Are the recent improvements to the
> > > > > > > > > maven-deploy-plugin strong enough the try and unite all
> > > > publishing
> > > > > > > > > plugins as one ?
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Jon
> > > > > > > > >
> > > > > > > > >
> > > > -
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > -
> > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > > > >
> > > > > > >
> > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
--
Guillaume Nodet
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
t;
> > Regards,
> >
> > Giovanni van der Schelde
>
>
>
> --
> Sławomir Jaranowski
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@
+1 to retire
Guillaume Nodet
Le sam. 19 juil. 2025 à 14:47, Slawomir Jaranowski
a écrit :
> +1 for retire
>
> On Tue, 15 Jul 2025 at 19:17, Matthias Bünger wrote:
> >
> > Hi everyone,
> > during migration from JIRA to GitHub we
Agreed
Guillaume Nodet
Le sam. 19 juil. 2025 à 14:43, Slawomir Jaranowski
a écrit :
> +1
>
> Make it officially retired
>
> On Tue, 15 Jul 2025 at 19:14, Matthias Bünger wrote:
> >
> > Hi everyone,
> > during migration from J
t
Fix ITs referencing rc-3-SNAPSHOT (#2164) @gnodet
[MNG-8620] - Fix links in SVG (#2152) @kwin
On behalf of the Apache Maven Team,
Guillaume Nodet
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional comman
Hi,
The vote has passed with 13 +1s and no other votes.
I'll publish the release asap.
Thanks,
Guillaume
+1
Le mer. 18 juin 2025 à 16:27, Guillaume Nodet a écrit :
>
> Hi,
>
> We solved the following issues:
>
> https://github.com/apache/maven/issues?q=is%3Aclosed%20milestone%3A4.0.0-rc-4
>
> There are still a couple of issues left in GitHub:
> https://github.com/apach
-LATEST/
Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html
Vote open for at least 72 hours.
[ ] +1
[ ] +0
[ ] -1
--
Guillaume Nodet
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
7cbt1qw
>
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
ge you'd like to include before the release, yell asap !
--
Guillaume Nodet
More verbose code. What’s the benefit?
Guillaume Nodet
Le mar. 3 juin 2025 à 23:05, Pankraz76 (via GitHub) a
écrit :
>
> Pankraz76 commented on code in PR #2425:
> URL: https://github.com/apache/maven/pull/2425#discussion_r2124918459
>
>
>
t;
> Are all those bits of “compatibility code” annotated as @Deprecated?
>
> Later,
>
> Andy
>
> From: Guillaume Nodet
> Date: Tuesday, 3 June 2025 at 09:20
> To: Maven Developers List
> Subject: Re: current setup is leaking quality: [S1161] "@override" shou
FWIW, most if not all of these changes are in compatibility (I.e.
deprecated) code, so while it can be worth fixing things, we should focus
on current / used code instead, so those changes are low priority imho.
Guillaume Nodet
Le mar. 3 juin 2025 à 09:47, Vincent
in the shell that
would fix those known incompatibilities, so that users would have an
easier migration path. And we could apply it to this project to make
more green boxes.
Le mer. 21 mai 2025 à 08:11, Guillaume Nodet a écrit :
>
> Hey Maven Devs,
>
> We're gearing up to rele
!
Cheers,
Guillaume Nodet
[1]
https://maven.apache.org/ref/4.0.0-rc-3/maven-impl-modules/maven-core/lifecycles.html
Le mar. 27 mai 2025 à 21:26, Sergey Chernov a écrit :
>
> Thanks for asking, I planned to raise this topic soon in the mailing list
>
> Here you can find a presentation b
ew RC. Overall I would
> > > prefer much more rigorous versioning. Right now we're pushing RCs with
> > > known unstable APIs, which I would normally consider appropriate for
> > > pre-alpha builds.
> > >
> >
> >
> > -
smaller
> > > > changes.
> > > > With current state of plugins 4.x they can't be used with latest
> > (master)
> > > > version so we could offer only 3.x for Maven 4.
> > > > Not so big issue for many users but without semi automatic way to
Rusty Harold a
écrit :
> On Sat, May 24, 2025 at 1:23 PM Guillaume Nodet wrote:
> >
> > I don't think they're talking about the Maven 4 API when they expect
> > API stability.
> > They rather refer to user-facing API such as schema changes, etc...,
>
Guillaume Nodet
Le dim. 25 mai 2025 à 13:30, Elliotte Rusty Harold a
écrit :
>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen.
Why is that so ? If you want to replace it
ate of plugins 4.x they can't be used with latest (master)
> > > version so we could offer only 3.x for Maven 4.
> > > Not so big issue for many users but without semi automatic way to move
> > > plugin to new public API we are selling new "untested internally".
thoughts on this approach?
Best,
Guillaume Nodet
Le mer. 21 mai 2025 à 10:13, Michael Osipov a écrit :
>
> On 2025/05/21 06:11:42 Guillaume Nodet wrote:
> > Hey Maven Devs,
> >
> > We're gearing up to release a new version from the master branch. I'm
> > th
Hey Maven Devs,
We're gearing up to release a new version from the master branch. I'm
thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
feedback or ideas on the versioning or release plan? Let’s hear it!
Cheers,
Guillaume
le.com/en/java/javase/24/docs/api/java.compiler/javax/tools/StandardJavaFileManager.html#setLocationForModule(javax.tools.JavaFileManager.Location,java.lang.String,java.util.Collection)
> >
> > Martin
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
--
Guillaume Nodet
lly for.
>
> Later,
>
> Andy
>
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336. Is e buidheann carthannais a th’ ann an
> Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
>
--
Guillaume Nodet
uction of that element so I can understand it better?
> > >
> > There are the wiki pages on the clone used for making the prototypes
> > before to submit the pull requests:
> >
> > * Maven core: https://github.com/Geomatys/maven/wiki
> > * Complier plugin:
> > https://github.com/Geomatys/maven-compiler-plugin/wiki
> >
> > Those pages, if accepted, would move to some Maven documentation site,
> > but I'm not sure where.
> >
> > Martin
> >
> >
>
--
Guillaume Nodet
>
>
> https://cwiki.apache.org/confluence/display/MAVEN/Default+directory+for+modular+projects
>
> What peoples think that the default should be?
>
> Martin
>
>
--
Guillaume Nodet
it Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
--
Guillaume Nodet
écrit :
> Could MAVEN_ARGS or MAVEN_OPTS be used for this?
>
> Gary
>
> On Thu, May 1, 2025 at 12:22 AM Guillaume Nodet wrote:
> >
> > The only way is to add the --enable-native-access=ALL-UNNAMED option in
> the
> > shell scripts afaik. We've already added it in ma
The only way is to add the --enable-native-access=ALL-UNNAMED option in the
shell scripts afaik. We've already added it in master.
Note that this option is not available in older JDK which are still
supported by Maven 3.9.
Guillaume Nodet
Le jeu. 1 mai 2025 à
Closing this vote with 6 +1s.
Le mer. 26 mars 2025 à 11:12, Guillaume Nodet a écrit :
> Hey,
>
> This release contains a few changes, mainly an upgrade to Maven
> 4.0.0-rc-3 which brought a few incompatible changes in the API and
> thus requires this update. This release als
+1
Le mer. 26 mars 2025 à 11:12, Guillaume Nodet a écrit :
> Hey,
>
> This release contains a few changes, mainly an upgrade to Maven
> 4.0.0-rc-3 which brought a few incompatible changes in the API and
> thus requires this update. This release also updates a few
> depende
ust add a new method to the abstract class that all of the
> implementations extend but I consider it a stopgap measure since this
> functionality would be useful to third party developers, etc.
>
> (Sidenote - it could even quietly replace some of the existing logic since
> the final method could easily perform a recursive descent of rootNode and
> call visit() and endVisit() itself. I think this could be put into the
> DependencyNodeVisitor interface as a default method so there would be no
> risk to removing the existing code. The primary drawback would be that the
> current approach allows the implementation to bail out early if it hits a
> problem while this approach would require the entire rootNode structure to
> be generated first.)
>
> Bear
>
--
Guillaume Nodet
; since the plugin has access to the raw pom it can look for any
> entries in the properties and then check whether that value is used in any
> dependencies. If so, esp. if it happens more than once, then it can be
> treated the same as above.
>
> Bear Giles
>
--
Guillaume Nodet
Hey,
This release contains a few changes, mainly an upgrade to Maven
4.0.0-rc-3 which brought a few incompatible changes in the API and
thus requires this update. This release also updates a few
dependencies.
Changes since the last release:
https://github.com/apache/maven-plugin-testing/compare/
hough?
> >
> > Martin
> >
> > [1]
> https://github.com/apache/maven/blob/master/api/maven-api-model/src/main/mdo/maven.mdo
> > [2]https://openjdk.org/jeps/468
> > [3]https://openjdk.org/jeps/440
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
To be clear, I'm fine with enhancing the generated model and experiment
with records.
But it can be done by modifying a single file rather than a few hundreds
for all generated model classes we have.
Le mar. 25 mars 2025 à 13:38, Guillaume Nodet a écrit :
> -1
>
> I'm fine
; >
> So what about this plan?
>
> * Check-in the generated classes as they are today.
> * Remove Modello.
> * Try on a branch to change the classes to record.
>
> Martin
>
>
--
Guillaume Nodet
the same way..
>
> Based on my assumption (coming from the name) would be called exactly
> once "before:all" ... "after:all" also..
> Because that would not solve the problem to bind a plugin like JaCoCo
> (for coverage for an aggregate) or JavaDoc for an aggregate for a whole
> project in it...
>
> Or do we have a solution for that which I'm not yet aware of?
>
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
and embeded version of asm 9.6:
> >
> >
> >
> >
> https://github.com/eclipse-sisu/sisu-project/pull/95/commits/c239adfad8eec92b85a33a431d4c5e2a4eff2dc7
> >
> > So I guess that needs updating and a new sisu plugin releasing. Will
> take
> > a look at patching that and trying it.
> >
> > Mark
> >
>
--
Guillaume Nodet
>
>
> - Maarten
>
> On 18/03/2025 12:24, Guillaume Nodet wrote:
> > The `all` phase is executed for each project. But you can avoid the
> plugin
> > execution to be inherited by setting inherited="false" on the execution.
> > I've spotted a bug I
fter:all" the same way..
>
> Based on my assumption (coming from the name) would be called exactly
> once "before:all" ... "after:all" also..
> Because that would not solve the problem to bind a plugin like JaCoCo
> (for coverage for an aggregate) or JavaDoc for an aggregate for a whole
> project in it...
>
> Or do we have a solution for that which I'm not yet aware of?
>
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
ing/ and see if someone
> has a counter-argument.
>
> Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
Sure, that’s clearly not what I understood when you specifically mentioned
« 4.0 poms ». Since we have no correlation between the Maven version and
the model version , I assumed the later when talking about poms.
Guillaume Nodet
Le lun. 17 mars 2025 à 18:03, Elliotte
27;t need to be in Maven.
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
--
Guillaume Nodet
publishing
the POMs, in particular for POMs that are crafted by other tools such as
Gradle and such. We should make sure they can be safely consumed before
they reach Maven Central.
> There are others. Those are just the most pressing ones off the top of
> my head that it's much less expen
;
> > 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
y aligned... So maybe we think
about it again ? I do think we want them to be roughly available at the
same time...
>
>
> On Sun, 16 Mar 2025 at 17:37, Guillaume Nodet wrote:
> >
> > I think it's time to create a branch to release Maven 4.0.0 GA in the
> >
Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
tml
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
I think it's time to create a branch to release Maven 4.0.0 GA in the
coming weeks and switch master to 4.1.0-SNAPSHOT.
Thoughts ?
--
Guillaume Nodet
the path forward?
>
> Cheers,
>
> Fred.
>
> On Fri, 24 Jan 2025 at 01:39, Elliotte Rusty Harold
> 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 IAN
;
> > > > > > 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
> > > >
25 à 09:51, Slawomir Jaranowski
a écrit :
>
> On Thu, 13 Mar 2025 at 22:14, Guillaume Nodet wrote:
> >
> > FYI, I came up with the following extension:
> > https://github.com/maveniverse/mason
>
> What status will be of the project
> https://github.com/apache/maven-h
consult:
- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the mvnd issue tracker: https://github.com/apache/maven-mvnd/issues
Regards,
On behalf of the Apache Maven Team
Guillaume Nodet
Closing this vote with 5 +1s.
I'll publish the release asap.
Le lun. 10 mars 2025 à 21:56, Guillaume Nodet a écrit :
>
> This release provides distributions based on Apache Maven 4.0.0-rc-3.
>
> The release candidate is here:
> https://dist.apache.org/repos/dist/dev/m
+1
Le lun. 10 mars 2025 à 21:56, Guillaume Nodet a écrit :
>
> This release provides distributions based on Apache Maven 4.0.0-rc-3.
>
> The release candidate is here:
> https://dist.apache.org/repos/dist/dev/maven/mvnd/2.0.0-rc-3/
>
> Release notes: (visible to committe
d like to get it into the Maven project and release it.
>
> [1] https://github.com/apache/maven-hocon-extension
> [2] https://github.com/gnodet/maven-yaml-extension
> [3]
> https://github.com/gnodet/maven-yaml-extension/blob/master/src/test/resou
.
--
Guillaume Nodet
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
NG-8593] - Resolver 2.0.7
[MNG-8595] - Bump slf4jVersion from 2.0.16 to 2.0.17
[MNG-8596] - Bump ch.qos.logback:logback-classic from 1.5.16 to 1.5.17
[MNG-8606] - Bump mockitoVersion from 5.15.2 to 5.16.0
[MNG-8607] - Bump net.bytebuddy:byte-buddy from 1.17.1 to 1.17.2
On behalf of the
Closing this vote with 13 +1s and no other votes.
I'll publish this release asap.
Cheers,
Guillaume
Le mer. 5 mars 2025 à 12:15, Guillaume Nodet a écrit :
> We solved 108 issues since rc-2.
> https://issues.apache.org/jira/projects/MNG/versions/12355493
>
> Staging reposi
+1
Le mer. 5 mars 2025 à 12:15, Guillaume Nodet a écrit :
> We solved 108 issues since rc-2.
> https://issues.apache.org/jira/projects/MNG/versions/12355493
>
> Staging repositories:
> https://repository.apache.org/content/repositories/maven-2278/
> https://dist.apache.
e:
> - maven plugins, like m-release-p or m-version-p (or ... please name
others you know)
> - IDEs
>
>
> I hope we'll manage to keep a concise useful discussion, and make some
progress on
> pom.xml maintenance
>
>
> Regards,
>
>
> Hervé
>
>
> [4] ht
ub.com/apache/maven-hocon-extension
[2] https://github.com/gnodet/maven-yaml-extension
[3]
https://github.com/gnodet/maven-yaml-extension/blob/master/src/test/resources/dependency-gav.yaml#L21-L30
--
----
Guillaume Nodet
--
Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html
The vote is opened for at least 72h:
[ ] +1
[ ] +0
[ ] -1
--
Guillaume Nodet
Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
Guillaume Nodet
org/resolver-archives/resolver-LATEST/upgrading-resolver.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apach
e open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
Guillaume Nodet
---
gt; patched version?
>
> Piotr
>
> [1] https://lists.apache.org/thread/4jt9j4x61rwxmbw30f5gdsfoxm1mmfzz
>
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
>
> > -----
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
anowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
should concern the
access to the resolver API, model building, etc...
Le mar. 11 févr. 2025 à 12:50, Elliotte Rusty Harold a
écrit :
> On Tue, Feb 11, 2025 at 7:20 AM Guillaume Nodet wrote:
> >
> > The resolver API should be avoided in the future as it's supposed
> >
gt; >>>>>> wrote:
> >>>>>>
> >>>>>>> On Mon, Feb 10, 2025 at 10:02 AM Xeno Amess
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Sometimes comments are used to embed additional
> >> machine-readable
> >>>>>>> metadata.
> >>>>>>>> yes and considering somebody would like to use this for a maven
> >>>>>> extension
> >>>>>>>> or something...
> >>>>>>>
> >>>>>>> Yes, that's a pretty common antipattern. Embedding other markup
> >>>>>>> formats inside XML is baroque, confusing, and tool hostile. The
> >>>> better
> >>>>>>> approach is to add additional XML markup to the document. In this
> >>>>>>> specific instance that means Maven would stop erroring if it sees
> >>>>>>> elements it doesn't recognize. That is, it asks the question "Do I
> >>>>>>> have everything I need to build this project?" instead of "Do I
> >>>>>>> understand every element in this pom?"
> >>>>>>>
> >>>>>>> A slightly less radical approach would be to ignore elements not
> >> in
> >>>>>>> Maven's own namespace.
> >>>>>>>
> >>>>>>> --
> >>>>>>> Elliotte Rusty Harold
> >>>>>>> elh...@ibiblio.org
> >>>>>>>
> >>>>>>>
> >>>> -
> >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
The resolver API should be avoided in the future as it's supposed
to be hidden by the Maven 4 API. So I'm not sure it's worth it.
Le mar. 11 févr. 2025 à 08:00, Xeno Amess a écrit :
> is it good to copy them for resolver?
>
> Guillaume Nodet 于2025年2月11日周二 13:56写道
> Any thoughts on this?
>
> /Anders
>
--
Guillaume Nodet
Maven 4 uses the following :
https://github.com/apache/maven/tree/master/api/maven-api-annotations/src/main/java/org/apache/maven/api/annotations
Guillaume Nodet
Le mar. 11 févr. 2025 à 05:35, Xeno Amess a écrit :
> as title.
> during recently learning about
e from the audience
> > who raised concern about comments in the build POM being removed in the
> > published consumer POM. They thought that could be problematic for larger
> > corporations who want, for example, copyright comments.
> >
> > Any thoughts on this?
> >
> > /Anders
> >
--
Guillaume Nodet
+1
Guillaume Nodet
Le mer. 5 févr. 2025 à 10:53, Tamás Cservenák a
écrit :
> Howdy,
>
> This Resolver 2.0.6 release is a bugfix release with some
> improvements as well.
>
> Maven 4.x is picking up Resolver 2.x, while Maven 3.x remains at
> Reso
---
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
subscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
--
Guillaume Nodet
es hard
coded heuristics and improvements would be welcomed. Or customization...
> Any opinions on the above two points? Otherwise I would just open issues
> for those.
>
>
> -Thomas
>
>
> On 03/02/2025 08:05, Guillaume Nodet wrote:
> > The toolchains discover
Closing this vote with 5 +1s, one +0
I'll publish this release asap.
Cheers,
Guillaume
Le mar. 28 janv. 2025 à 07:50, Guillaume Nodet a écrit :
> This release is mainly about to upgrade to Maven 4.0.0-rc-2.
>
> Release notes:
>
> https://github.com/apache/maven-plugin-
+1
Le mar. 28 janv. 2025 à 07:50, Guillaume Nodet a écrit :
> This release is mainly about to upgrade to Maven 4.0.0-rc-2.
>
> Release notes:
>
> https://github.com/apache/maven-plugin-testing/releases/tag/untagged-20178e0448cab098704e
>
> There are still a couple of issu
gt; Thanks for all comments.
> >>
> >>
> >> Sincerely,
> >> Mikko Koivunalho
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> --
> Mikko Koivunalho
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Guillaume Nodet
1 - 100 of 666 matches
Mail list logo
