Re: [DISCUSS] maven-core-plugin

le new plugin name Of course "maven-core-plugin" is just a first initial name: any better idea to match the intent of the new merged plugin is welcome > > I'm just asking because: > > 1) It would invalidate each and every custom configuration / executions +1 > 2)

Re: [DISCUSS] maven-core-plugin

"maven-" jars including 10 "maven-resolver-". Why don't I just a single "maven-core" jar? Gary On Sun, Aug 18, 2024, 7:04 AM Konrad Windszus wrote: On 18. Aug 2024, at 12:59, Hervé Boutemy wrote: with Maven 4, we'll have to maintain a 4.x branch of eac

Re: [DISCUSS] maven-core-plugin

2:34 PM Gary Gregory > > > > wrote: > > > > Another way to look at a "core": > > > > > > > > In my Maven 3.9.8 install folder I have 23 "maven-" jars including 10 > > > > "maven-resolver-". Why don

Re: [DISCUSS] maven-core-plugin

scope, as any other plugin: a plugin with more than 10 goals in general tends to be hard to simply document, like we have experience with dependency plugin for example > > as a user, it's true that these plugins are used in each and every > > packaging bindings > > https:/

Re: [DISCUSS] maven-core-plugin

code among > plugins ? > > > > On Sun, Aug 18, 2024, 2:34 PM Gary Gregory > wrote: > > > > > Another way to look at a "core": > > > > > > In my Maven 3.9.8 install folder I have 23 "maven-" jars including 10 > > > &quo

Re: [DISCUSS] maven-core-plugin

2024, 2:34 PM Gary Gregory wrote: > > > Another way to look at a "core": > > > > In my Maven 3.9.8 install folder I have 23 "maven-" jars including 10 > > "maven-resolver-". Why don't I just a single "maven-core" jar? > >

Re: [DISCUSS] maven-core-plugin

among plugins ? On Sun, Aug 18, 2024, 2:34 PM Gary Gregory wrote: > Another way to look at a "core": > > In my Maven 3.9.8 install folder I have 23 "maven-" jars including 10 > "maven-resolver-". Why don't I just a single "maven-core&quo

Re: [DISCUSS] maven-core-plugin

Another way to look at a "core": In my Maven 3.9.8 install folder I have 23 "maven-" jars including 10 "maven-resolver-". Why don't I just a single "maven-core" jar? Gary On Sun, Aug 18, 2024, 7:04 AM Konrad Windszus wrote: > > > > On 1

Re: [DISCUSS] maven-core-plugin

it is all or nothing for those mojos). > as a user, it's true that these plugins are used in each and every packaging > bindings https://maven.apache.org/ref/3.9.9/maven-core/default-bindings.html > , > having only one version to drive them would be nice > > Regards,

Re: [DISCUSS] maven-core-plugin

alue we get from it: as a Maven dev, it's true that clean, install and deploy have few releases. Resources seem to have a current issue reported by Konrad, I need to understand... as a user, it's true that these plugins are used in each and every packaging bindings https://maven.apac

Re: [DISCUSS] maven-core-plugin

Having N module in a single repo is not a game changer in terms of releases IMHO, if so our tooling is bad and can be enhanced so only question is all in a single plugins (monoproject/module) or nothing, no? Le sam. 17 août 2024 à 10:30, Christoph Läubrich a écrit : > Just wanted to mention that

Re: [DISCUSS] maven-core-plugin

Just wanted to mention that even if many project/modules/... are in the same git-repository (and probably having a "common" code) does not mean one can't deploy/build/... them individually. Am 17.08.24 um 09:39 schrieb Olivier Lamy: Hi Not sure to understand the structure of this and the rel

Re: [DISCUSS] maven-core-plugin

Hi Not sure to understand the structure of this and the release cycle and if this includes maintenance of maven3 branches of plugins. If I understand correctly when cutting a release we will cut a release of every plugins? On Fri, 16 Aug 2024 at 10:00 PM, Ozgun Oz wrote: > Just an outsider here,

Re: [DISCUSS] maven-core-plugin

different codes,  I'm for this move forward. Only thing I'm not sure about is the name "maven-core" for me as a fresh guy here always relates to the maven core application but not the plugins - I guess you mean the core basic plugins, but maybe a different name like idk (names...)

Re: [DISCUSS] maven-core-plugin

Just an outsider here, but I agree with Guillaume. Also I think Tamas' proposal is to merge the existing plugins, so the repo of the old plugins will be probably archived and the old plugins code will be moved to the new plugin repo. Since the old plugins will not evolve and maintained by ASF, and

Re: [DISCUSS] maven-core-plugin

Well this would be the same plugins, not duplicates…. Guillaume Nodet Le jeu. 15 août 2024 à 20:10, Elliotte Rusty Harold a écrit : > On Thu, Aug 15, 2024 at 1:24 PM Delany wrote: > > > The $5000 question is how can the old plugins still even exist if the > code > >

Re: [DISCUSS] maven-core-plugin

On Thu, Aug 15, 2024 at 1:24 PM Delany wrote: > The $5000 question is how can the old plugins still even exist if the code > for them has been moved to a new core plugin? In the git repo. In Maven central. In absolutely every existing plugin and build that depends on these today. They aren't go

Re: [DISCUSS] maven-core-plugin

hese mojos to a new plugin? Delany On Thu, 15 Aug 2024 at 17:49, Elliotte Rusty Harold wrote: > No, it seems to be a proposal for a new core plugin, not just > reorganzing the git repo. I predict if someone tries that we'll still > have all the old plugins plus the new maven-

Re: [DISCUSS] maven-core-plugin

No, it seems to be a proposal for a new core plugin, not just reorganzing the git repo. I predict if someone tries that we'll still have all the old plugins plus the new maven-core-plugin. I have seen this play out so many times over the years. Another old favorite: https://www.youtube.com/

Re: [DISCUSS] maven-core-plugin

> > plugin X "this should be shared with Y") > > > * some "forcefully" pushed out "shared" artifact to share them across > > > * just many too small codebases that needs a LOT of process/work effort > > for > > > small gain > &

Re: [DISCUSS] maven-core-plugin

AFAIK, Tamas suggested to *move* all plugins in a single maven-core-plugin, not to extract reusable data in a new git repo. Le jeu. 15 août 2024 à 15:42, Christoph Läubrich a écrit : > > I think the main problem is that "maven-core" is often rejecting request > for providi

Re: [DISCUSS] maven-core-plugin

ike > > in > > > plugin X "this should be shared with Y") > > > * some "forcefully" pushed out "shared" artifact to share them across > > > * just many too small codebases that needs a LOT of process/work effort > > for > > &

Re: [DISCUSS] maven-core-plugin

uld be shared with Y") > > * some "forcefully" pushed out "shared" artifact to share them across > > * just many too small codebases that needs a LOT of process/work effort > for > > small gain > > * it is all chopped up into relatively small pie

Re: [DISCUSS] maven-core-plugin

t; small gain > * it is all chopped up into relatively small pieces > > Hence, we were already discussing this idea on Slack: what if we introduce > maven-core-plugin? > > One single plugin that contains some "most common" Mojos? > (nothing new under Sun, this wo

Re: [DISCUSS] maven-core-plugin

24, at 13:13, Tamás Cservenák > > wrote: > > > >> > > > >> Howdy, > > > >> > > > >> as am going over multiple plugins (as it is time to upgrade parent, > > some > > > >> bugfix, etc), all I see is: > > &g

Re: [DISCUSS] maven-core-plugin

ultiple plugins (as it is time to upgrade parent, > some > > >> bugfix, etc), all I see is: > > >> * a LOT of code duplication across plugins (some even have comments > > like in > > >> plugin X "this should be shared with Y") > > >>

Re: [DISCUSS] maven-core-plugin

I think the main problem is that "maven-core" is often rejecting request for providing useful things in the first place. That leads to all kind of "helper", "util", ... so maybe instead of having a maven-core-plugin, it would better to have a maven-plugin-core

Re: [DISCUSS] maven-core-plugin

be shared with Y") > >> * some "forcefully" pushed out "shared" artifact to share them across > >> * just many too small codebases that needs a LOT of process/work effort > for > >> small gain > >> * it is all chopped up into relatively

Re: [DISCUSS] maven-core-plugin

quot;shared" artifact to share them across > * just many too small codebases that needs a LOT of process/work effort for > small gain > * it is all chopped up into relatively small pieces > > Hence, we were already discussing this idea on Slack: what if we introduce >

Re: [DISCUSS] maven-core-plugin

s that needs a LOT of process/work effort for >> small gain >> * it is all chopped up into relatively small pieces >> >> Hence, we were already discussing this idea on Slack: what if we introduce >> maven-core-plugin? >> >> One single plugin that contains some

Re: [DISCUSS] maven-core-plugin

d be shared with Y") > * some "forcefully" pushed out "shared" artifact to share them across > * just many too small codebases that needs a LOT of process/work effort for > small gain > * it is all chopped up into relatively small pieces > > Hence, we were already

[DISCUSS] maven-core-plugin

artifact to share them across * just many too small codebases that needs a LOT of process/work effort for small gain * it is all chopped up into relatively small pieces Hence, we were already discussing this idea on Slack: what if we introduce maven-core-plugin? One single plugin that contains some

Re: [DISCUSS] Maven Core Plugins versioning

ransition, a > plugin > > version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3 > > plugin" (Maven2 incompatible). > > > > As otherwise, if we start releasing Core plugins 4.x or 5.x, we will > > confuse the hell out of our users. A

Re: [DISCUSS] Maven Core Plugins versioning

2 incompatible). > > As otherwise, if we start releasing Core plugins 4.x or 5.x, we will > confuse the hell out of our users. At least that is what I think. > > II. Consequence: How to interpret Core plugin versions > > As can be seen above, so far the major version of the pl

Re: [DISCUSS] Maven Core Plugins versioning

Gary, "core plugins" are controlled by us, and they always followed this "standard" (version major was showing Maven API level). But true, for EXTERNAL plugins, this will be quite an interesting thing. They will probably solve the "migrated to Maven 4 API" by major version bump. Maven2 was "shor

Re: [DISCUSS] Maven Core Plugins versioning

On Fri, Mar 8, 2024, 2:56 PM Michael Osipov wrote: > Am 2024-03-08 um 20:51 schrieb Gary Gregory: > > IMO, the old version + 0.10 is a recipe for confusion and explanations > for > > this and that exception. > > I totally agree with you, that is a horrible compromise. Do you see a > better way to

Re: [DISCUSS] Maven Core Plugins versioning

nák: > >>> I agree with Gary, > >>> > >>> really really the simplest would be to NOT use Doxia 2 for Maven 3, as > >>> basically that IS the "plugin breakage" we are soon facing. > >> > >> This is unacceptable for me because t

Re: [DISCUSS] Maven Core Plugins versioning

ople to move off Maven 3 because of site generation. This is not a core issue since reporting has been removed from Maven Core in Maven 3 for good. Please DO NOT conflate what has been untangled 10+ years ago. I can/will use a minor release with a special section in the release notes since next major is unvailable. M

Re: [DISCUSS] Maven Core Plugins versioning

; > basically that IS the "plugin breakage" we are soon facing. >> >> This is unacceptable for me because that breaks two years of ongoing >> effort. I cannot expect people to move off Maven 3 because of site >> generation. This is not a core issue since reporting h

Re: [DISCUSS] Maven Core Plugins versioning

ct people to move off Maven 3 because of site > generation. This is not a core issue since reporting has been removed > from Maven Core in Maven 3 for good. Please DO NOT conflate what has > been untangled 10+ years ago. I can/will use a minor release with a > special section in the release notes since next major is unvailable. > > M >

Re: [DISCUSS] Maven Core Plugins versioning

not expect people to move off Maven 3 because of site generation. This is not a core issue since reporting has been removed from Maven Core in Maven 3 for good. Please DO NOT conflate what has been untangled 10+ years ago. I can/will use a minor release with a special section in the release notes

Re: [DISCUSS] Maven Core Plugins versioning

I agree with Gary, really really the simplest would be to NOT use Doxia 2 for Maven 3, as basically that IS the "plugin breakage" we are soon facing. T On Fri, Mar 8, 2024 at 8:53 PM Gary Gregory wrote: > IMO, the old version + 0.10 is a recipe for confusion and explanations for > this and tha

Re: [DISCUSS] Maven Core Plugins versioning

Am 2024-03-08 um 20:51 schrieb Gary Gregory: IMO, the old version + 0.10 is a recipe for confusion and explanations for this and that exception. I totally agree with you, that is a horrible compromise. Do you see a better way to reconcile both issues? I don't see any :-( ---

Re: [DISCUSS] Maven Core Plugins versioning

IMO, the old version + 0.10 is a recipe for confusion and explanations for this and that exception. Gary On Fri, Mar 8, 2024, 2:40 PM Tamás Cservenák wrote: > Maarten, > > that would need a LOT of work, from maven plugin tools, IDEs and ALL the > stuff that _assumes_ that a plugin artifactId is

Re: [DISCUSS] Maven Core Plugins versioning

Maarten, that would need a LOT of work, from maven plugin tools, IDEs and ALL the stuff that _assumes_ that a plugin artifactId is either "maven-xxx-plugin" or "xxx-maven-plugin". Never looked into, but I guess that would be quite a big impact. T On Fri, Mar 8, 2024 at 8:22 PM Maarten Mulders w

Re: [DISCUSS] Maven Core Plugins versioning

It might've been proposed and rejected before, but how about 1. maven4-compiler-plugin -or- 2. maven-compiler-plugin (with maven4/maven5/etc classifier) In both scenario's, we could still use semantic versioning as we do right now, and as Maven users probably expect us to adhere to. Thanks,

Re: [DISCUSS] Maven Core Plugins versioning

Am 2024-03-08 um 17:20 schrieb Guillaume Nodet: I'm slightly hesitant about that. It seems to me plugins have mostly been compatible, so we very rarely used a major version switch, but we do have plugins in 3.12.1 for example, which would be translated to 3.0.12.1. Not even sure how the 4th digi

Re: [DISCUSS] Maven Core Plugins versioning

Or maybe a 1 hundred bump: 3.12.1 -> 3.100.0 ? It may be more clear, as that's a number we don't usually reach... Le ven. 8 mars 2024 à 17:20, Guillaume Nodet a écrit : > > I'm slightly hesitant about that. > It seems to me plugins have mostly been compatible, so we very rarely > used a major v

Re: [DISCUSS] Maven Core Plugins versioning

I'm slightly hesitant about that. It seems to me plugins have mostly been compatible, so we very rarely used a major version switch, but we do have plugins in 3.12.1 for example, which would be translated to 3.0.12.1. Not even sure how the 4th digit is supported... I wonder if an alternative propo

Re: [DISCUSS] Maven Core Plugins versioning

+1 Am 08.03.2024 um 13:00 schrieb Tamás Cservenák: So, can we agree on following (maybe even vote if needed)? I. Core Plugin Versioning Maven3 plugins carry 3.x as the major version number, and Maven4 plugins will carry 4.x major versions? II. Consequence: How to interpret Core plugin versions

Re: [DISCUSS] Maven Core Plugins versioning

+1 without any strong opinion on doxia 2 for maven 3 in the future (no blocker IMHO but not the baseline too) Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github

Re: [DISCUSS] Maven Core Plugins versioning

So, can we agree on following (maybe even vote if needed)? I. Core Plugin Versioning Maven3 plugins carry 3.x as the major version number, and Maven4 plugins will carry 4.x major versions? II. Consequence: How to interpret Core plugin versions See above. In short: the first element is "maven API

Re: [DISCUSS] Maven Core Plugins versioning

And a short addendum: Given, today there are still no Maven 4.x plugins nor Doxia 2.x reports out there (released), what if, we follow Michael intent BUT with a slight "bend": - the new Maven Site plugin that uses Doxia 2.0.0 and would carry version 4.0.0 (to be released) **should be Maven4 plugin

Re: [DISCUSS] Maven Core Plugins versioning

Just to clarify, explain myself but also FTR on thread: in case of report-plugins we basically have TWO requirements (or deps): - maven API level - doxia API level (that with 2.0.0 contains breaking changes) Basically, Maven4 supports 4.x plugins (that use new API) but also supports running 3,x p

Re: [DISCUSS] Maven Core Plugins versioning

Hi Michael, Site 4.0.0 does not exist, there are only milestones (so no guarantee given in such a release) so not a big deal IMHO, we can align on Tamas proposal and just do a 3.(n+1) if we want to propose the changes to maven 3 (no big opinion on this one). So proposal sounds good to me: $maven.

Re: [DISCUSS] Maven Core Plugins versioning

Howdy, First, 4.0 is not out yet (check my remark in the initial mail "M releases do not count"). Second, is there a plugin out there that also includes a report? (or in other words, you remember I was insisting to SPLIT OUT all the report stuff out of plugins) As if there is no such plugin, we

Re: [DISCUSS] Maven Core Plugins versioning

Am 2024-03-08 um 11:19 schrieb Tamás Cservenák: So, can we agree on following (maybe even vote if needed)? I. Core Plugin Versioning Maven3 plugins carry 3.x as the major version number, and Maven4 plugins will carry 4.x major versions? See Maven Site Plugin 4.0, contains fundemantal changes i

Re: [DISCUSS] Maven Core Plugins versioning

Sounds good to me. /Anders (mobile) Den fre 8 mars 2024 11:19Tamás Cservenák skrev: > So, can we agree on following (maybe even vote if needed)? > > I. Core Plugin Versioning > Maven3 plugins carry 3.x as the major version number, and Maven4 plugins > will carry 4.x major versions? > > II. Cons

Re: [DISCUSS] Maven Core Plugins versioning

So, can we agree on following (maybe even vote if needed)? I. Core Plugin Versioning Maven3 plugins carry 3.x as the major version number, and Maven4 plugins will carry 4.x major versions? II. Consequence: How to interpret Core plugin versions See above. In short: the first element is "maven API

Re: [DISCUSS] Maven Core Plugins versioning

Michael, I am unsure why it would not work? As I explained in my initial email, Maven2 plugins were 2.x, Maven3 plugins were 3.x, so why could not Maven4 be 4.x? I think that "maven plugin" is quite well defined (is not "just a jar"). While I would expect your "bump the major version" for some lib

Re: [DISCUSS] Maven Core Plugins versioning

This is a general problem and cannot be solved. As soon as you need to break the plugin compat you need to bump the major version. That breakage does not need to be related to Maven at all. Upshot: No matter what you do, you will do it wrong. I would rely on MPLUGIN foo to manage he compat histo

Re: [DISCUSS] Maven Core Plugins versioning

I think. > > II. Consequence: How to interpret Core plugin versions > > As can be seen above, so far the major version of the plugin was kinda > showing "which Maven API level" is the plugin. > > So, it begs the question: HOW to interpret the Maven Core Plugin ver

Re: [DISCUSS] Maven Core Plugins versioning

w.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 6 mars 2024 à 15:16, Tamás Cservenák a écrit : > +1 to that definition > > On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus wrote: > > > Maven Core plugins are listed in https://maven.apache.org/plugin

Re: [DISCUSS] Maven Core Plugins versioning

maintained by the Apache Maven Project (not only core plugin according to the definition from above). Konrad > On 6. Mar 2024, at 15:12, Tamás Cservenák wrote: > > Gary, > > maven "core plugins" are these > https://maven.apache.org/plugins/ > > In short, Maven p

Re: [DISCUSS] Maven Core Plugins versioning

+1 to that definition On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus wrote: > Maven Core plugins are listed in https://maven.apache.org/plugins/. > But I would say that this versioning policy applies to all plugins in > groupId org.apache.maven.plugins….. > > Konrad > > &g

Re: [DISCUSS] Maven Core Plugins versioning

Gary, maven "core plugins" are these https://maven.apache.org/plugins/ In short, Maven plugins that are maintained by this project at ASF. While there is a quite overlap with mojohaus etc, they are NOT core plugins T On Wed, Mar 6, 2024 at 3:09 PM Gary Gregory wrote: > One iss

Re: [DISCUSS] Maven Core Plugins versioning

Maven Core plugins are listed in https://maven.apache.org/plugins/. But I would say that this versioning policy applies to all plugins in groupId org.apache.maven.plugins….. Konrad > On 6. Mar 2024, at 15:06, Gary Gregory wrote: > > One issue from a non-Maven dev (me) is that I hav

Re: [DISCUSS] Maven Core Plugins versioning

these, we MUST align on these IMHO. T On Wed, Mar 6, 2024 at 3:05 PM Romain Manni-Bucau wrote: > Hi Tamas, > > Not sure I really got the issue, is it to do a breaking change without a > maven-core bump? > > I tend to agree with you, ie the versioning is > $mavenCoreMajor.$

Re: [DISCUSS] Maven Core Plugins versioning

we will > confuse the hell out of our users. At least that is what I think. > > II. Consequence: How to interpret Core plugin versions > > As can be seen above, so far the major version of the plugin was kinda > showing "which Maven API level" is the plugin. > &g

Re: [DISCUSS] Maven Core Plugins versioning

One issue from a non-Maven dev (me) is that I have no idea what is a Maven "core" plugin vs. not. I would make that obvious for users, and no, the "maven-" prefix does not make it obvious: maven-clean-plugin -> maven-core-clean-plugin or maven4-core-clean-plugin I'

Re: [DISCUSS] Maven Core Plugins versioning

Hi Tamas, Not sure I really got the issue, is it to do a breaking change without a maven-core bump? I tend to agree with you, ie the versioning is $mavenCoreMajor.$pluginMajor.$pluginMinor and no patch digit and guess it works good enough even for users, no? Best, Romain Manni-Bucau

[DISCUSS] Maven Core Plugins versioning

what I think. II. Consequence: How to interpret Core plugin versions As can be seen above, so far the major version of the plugin was kinda showing "which Maven API level" is the plugin. So, it begs the question: HOW to interpret the Maven Core Plugin version? My interpretation was a

Re: [DISCUSS] New Maven Core API for 4.x

> released with each version of maven. >> >> The current API can be seen at [1]. Note that the plugins API has also >> been included within the new API and the plugin tools have been updated so >> that the maven-plugin-plugin supports both v3 api and the new v4 api. A &g

Re: [DISCUSS] New Maven Core API for 4.x

so that it can finally > upgrade > > to > > > > a v2 with the package renamed without too much disturbance > > > > > > > > The goal would be to extract the models and API in a separate project > > > with > > > > a much lower release

Re: [DISCUSS] New Maven Core API for 4.x

Hmm, can mean reviewing on github the actual impact of such a deep breaking change. If too much outside our own code it can not be an option without a compat layer for a very long time, if very rare let's mive forward I'd say. But clearly we need a real plugin api and disable all

Re: [DISCUSS] New Maven Core API for 4.x

ing: no change in any plugin nor plugin api but same goal > being reached. In other words we have: > > 1. maven-core which uses whatever he wants to reach the programming model > we think is good (immutability) > 2. @Parameter MavenProject which becomes an API delegating to 1 (but is

Re: [DISCUSS] New Maven Core API for 4.x

gt; being reached. In other words we have: > > 1. maven-core which uses whatever he wants to reach the programming model > we think is good (immutability) > 2. @Parameter MavenProject which becomes an API delegating to 1 (but is > never the internal MavenProject instance) > > (ind

Re: [DISCUSS] New Maven Core API for 4.x

which can handle the manager and actual project usage as expected by maven. The impact being: no change in any plugin nor plugin api but same goal being reached. In other words we have: 1. maven-core which uses whatever he wants to reach the programming model we think is good (immutabili

Re: [DISCUSS] New Maven Core API for 4.x

* offer an homogeneous and a bit more modern API > > > > * completely hide the maven-resolver, so that it can finally > upgrade > > to > > > > a v2 with the package renamed without too much disturbance > > > > > > > > The goal would be to extr

Re: [DISCUSS] New Maven Core API for 4.x

We’re over at https://github.com/repaint-io/maven-tiles What we’re doing is essential “evil” and mixing in “tiles” as implicit parents. It’s it’s no longer possible with 4.x - and if 4.x could provide something similar, with a transition path we could document, I’m down with sunsetting the proj

Re: [DISCUSS] New Maven Core API for 4.x

Le lun. 28 mars 2022 à 21:22, Mark Derricutt a écrit : > I wonder how much of this will break what we do with the > tiles-maven-plugin, where we essentially “inject” parents into the model > via a maven extension. > Interesting. Do you have a pointer to that plugin's source code ? Guillaume

Re: [DISCUSS] New Maven Core API for 4.x

I wonder how much of this will break what we do with the tiles-maven-plugin, where we essentially “inject” parents into the model via a maven extension. I remember I was seeing some odd issues under earlier builds of 4.x as well some time ago but will need to refresh my memory on what that was no

Re: [DISCUSS] New Maven Core API for 4.x

project > > with > > > a much lower release cycle, as those rarely change, but are currently > > > released with each version of maven. > > > > > > The current API can be seen at [1]. Note that the plugins API has also > > > been included within the ne

Re: [DISCUSS] New Maven Core API for 4.x

been included within the new API and the plugin tools have been updated > so > > that the maven-plugin-plugin supports both v3 api and the new v4 api. A > > new flag has been added to the MojoDescriptor to know if the plugin is > > using the old or the new api. The plugin test

Re: [DISCUSS] New Maven Core API for 4.x

he current API can be seen at [1]. Note that the plugins API has also > > been included within the new API and the plugin tools have been updated > so > > that the maven-plugin-plugin supports both v3 api and the new v4 api. A > > new flag has been added to the MojoDescriptor to kn

Re: [DISCUSS] New Maven Core API for 4.x

> using the old or the new api. The plugin testing harness tools have been > updated to junit 5 and now provide a few annotations [2] to help writing > plugin tests [3]. The maven-core has been enhanced to support loading > those new v4 plugins along with the v3 ones, which means t

Re: [DISCUSS] New Maven Core API for 4.x

; > been included within the new API and the plugin tools have been > updated so > > > that the maven-plugin-plugin supports both v3 api and the new v4 api. > A > > > new flag has been added to the MojoDescriptor to know if the plugin is > > > using the old or the n

Re: [DISCUSS] New Maven Core API for 4.x

scriptor to know if the plugin is > > using the old or the new api. The plugin testing harness tools have been > > updated to junit 5 and now provide a few annotations [2] to help writing > > plugin tests [3]. The maven-core has been enhanced to support loading > > thos

Re: [DISCUSS] New Maven Core API for 4.x

I and the plugin tools have been updated so > that the maven-plugin-plugin supports both v3 api and the new v4 api. A > new flag has been added to the MojoDescriptor to know if the plugin is > using the old or the new api. The plugin testing harness tools have been > updated to junit 5 and

Re: [DISCUSS] New Maven Core API for 4.x

a new project with the new API and models, make sure plugins can work correctly with the new API / implementation * release the API, then maven-core supporting the new API do you think that we would do first Maven 4.0.0-alpha releases as 1 global release, to have a first stabilisation, before

Re: [DISCUSS] New Maven Core API for 4.x

I and models, make > sure plugins can work correctly with the new API / implementation > * release the API, then maven-core supporting the new API do you think that we would do first Maven 4.0.0-alpha releases as 1 global release, to have a first stabilisation, before splitting the API+model

Re: [DISCUSS] New Maven Core API for 4.x

lugin supports both v3 api and the new v4 api. A > > new flag has been added to the MojoDescriptor to know if the plugin is > > using the old or the new api. The plugin testing harness tools have been > > updated to junit 5 and now provide a few annotations [2] to help writing >

Re: [DISCUSS] New Maven Core API for 4.x

is using the old or the new api. The plugin testing harness tools have been updated to junit 5 and now provide a few annotations [2] to help writing plugin tests [3]. The maven-core has been enhanced to support loading those new v4 plugins along with the v3 ones, which means they can work side-by-si

Re: [DISCUSS] New Maven Core API for 4.x

included within the new API and the plugin tools have been updated so > that the maven-plugin-plugin supports both v3 api and the new v4 api. A > new flag has been added to the MojoDescriptor to know if the plugin is > using the old or the new api. The plugin testing harness tool

[DISCUSS] New Maven Core API for 4.x

ness tools have been updated to junit 5 and now provide a few annotations [2] to help writing plugin tests [3]. The maven-core has been enhanced to support loading those new v4 plugins along with the v3 ones, which means they can work side-by-side in the same build. This is done by implementing the

Re: Why are we shading in Maven Core

ove, that uses non-shaded > http-client) and maven-test-extension (repo above), the result shows that > - http-client IS visible in core-extension > - http-client IS NOT visible in build-extension > - http-client IS NOT visible in mojo > > IMHO, this is "as expected". >

Why are we shading in Maven Core

- http-client IS NOT visible in build-extension - http-client IS NOT visible in mojo IMHO, this is "as expected". Hence, IMHO we should stop shading stuff in Maven core, as http-client is NOT leaking into plugins and build-extensions. Question is core extensions that DOES see http-c

[GitHub] [maven-artifact-transfer] slachiewicz closed pull request #42: Bump maven-core from 3.0 to 3.8.2

slachiewicz closed pull request #42: URL: https://github.com/apache/maven-artifact-transfer/pull/42 -- This is an automated message from the Apache Git 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

[GitHub] [maven-artifact-transfer] dependabot[bot] commented on pull request #42: Bump maven-core from 3.0 to 3.8.2

dependabot[bot] commented on pull request #42: URL: https://github.com/apache/maven-artifact-transfer/pull/42#issuecomment-899460667 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next majo

[GitHub] [maven-artifact-transfer] dependabot[bot] opened a new pull request #42: Bump maven-core from 3.0 to 3.8.2

dependabot[bot] opened a new pull request #42: URL: https://github.com/apache/maven-artifact-transfer/pull/42 Bumps [maven-core](https://github.com/apache/maven) from 3.0 to 3.8.2. Commits https://github.com/apache/maven/commit/ea98e05a04480131370aa0c110b8c54cf726c06f

  1   2   3   4   5   6   7   8   9   10   >