Re: Java version for Maven 4?

[Xeno Amess]

well I just doubt.

From: Xeno Amess 
Sent: Tuesday, February 6, 2024 12:18:42 PM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

well nothing affensive but do any guys got any payments from those still-java-6 
companies for maintaining maven for them？

From: Gary Gregory 
Sent: Tuesday, February 6, 2024 6:14:32 AM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.

Gary

On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Elliotte,
>
> > Java 11 support is already EOL for most vendor until you go "premium"
> > flavor which will likely be very few people and most of them will be able
> > to pay somebody to backport the needed stuff in custom distro of their
> work
> > if needed anyday so not sure we should consider it.
>
> At least three big tech companies I know of build their own JDKs. At
> least one, possibly two, ship and support older JDKs for their
> customers. None of them are tied to Oracle and what Oracle is willing
> to support. If Oracle and all its data went to the great bit bucket in
> the sky tomorrow, they'd keep right on rolling. It would not even be a
> speed bump. They don't pay for premium support. They compete to
> provide premium support.*
>
> * There are some caveats here I won't go into for confidentiality
> reasons, but I can say that Azul's business model works.
>
> > On the other side most libraries tend to move forward faster and if you
> > like big ones, i'll take Spring or JakartaEE as an example - big user
> base
> > rather than big company$ ;) - and they don't even support Java 11
> anymore.
>
> Used by big tech customers. Not so much used by big tech companies
> themselves, that tend to run on stacks developed in house over more
> than a decade.
>
> --
> 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
>
>

Re: Java version for Maven 4?

[Xeno Amess]

well nothing affensive but do any guys got any payments from those still-java-6 
companies for maintaining maven for them？

From: Gary Gregory 
Sent: Tuesday, February 6, 2024 6:14:32 AM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.

Gary

On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Elliotte,
>
> > Java 11 support is already EOL for most vendor until you go "premium"
> > flavor which will likely be very few people and most of them will be able
> > to pay somebody to backport the needed stuff in custom distro of their
> work
> > if needed anyday so not sure we should consider it.
>
> At least three big tech companies I know of build their own JDKs. At
> least one, possibly two, ship and support older JDKs for their
> customers. None of them are tied to Oracle and what Oracle is willing
> to support. If Oracle and all its data went to the great bit bucket in
> the sky tomorrow, they'd keep right on rolling. It would not even be a
> speed bump. They don't pay for premium support. They compete to
> provide premium support.*
>
> * There are some caveats here I won't go into for confidentiality
> reasons, but I can say that Azul's business model works.
>
> > On the other side most libraries tend to move forward faster and if you
> > like big ones, i'll take Spring or JakartaEE as an example - big user
> base
> > rather than big company$ ;) - and they don't even support Java 11
> anymore.
>
> Used by big tech customers. Not so much used by big tech companies
> themselves, that tend to run on stacks developed in house over more
> than a decade.
>
> --
> 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
>
>

Re: Java version for Maven 4?

[Gary Gregory]

An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.

Gary

On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Elliotte,
>
> > Java 11 support is already EOL for most vendor until you go "premium"
> > flavor which will likely be very few people and most of them will be able
> > to pay somebody to backport the needed stuff in custom distro of their
> work
> > if needed anyday so not sure we should consider it.
>
> At least three big tech companies I know of build their own JDKs. At
> least one, possibly two, ship and support older JDKs for their
> customers. None of them are tied to Oracle and what Oracle is willing
> to support. If Oracle and all its data went to the great bit bucket in
> the sky tomorrow, they'd keep right on rolling. It would not even be a
> speed bump. They don't pay for premium support. They compete to
> provide premium support.*
>
> * There are some caveats here I won't go into for confidentiality
> reasons, but I can say that Azul's business model works.
>
> > On the other side most libraries tend to move forward faster and if you
> > like big ones, i'll take Spring or JakartaEE as an example - big user
> base
> > rather than big company$ ;) - and they don't even support Java 11
> anymore.
>
> Used by big tech customers. Not so much used by big tech companies
> themselves, that tend to run on stacks developed in house over more
> than a decade.
>
> --
> 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
>
>

Re: Java version for Maven 4?

[Elliotte Rusty Harold]

On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau  wrote:
>
> Hi Elliotte,

> Java 11 support is already EOL for most vendor until you go "premium"
> flavor which will likely be very few people and most of them will be able
> to pay somebody to backport the needed stuff in custom distro of their work
> if needed anyday so not sure we should consider it.

At least three big tech companies I know of build their own JDKs. At
least one, possibly two, ship and support older JDKs for their
customers. None of them are tied to Oracle and what Oracle is willing
to support. If Oracle and all its data went to the great bit bucket in
the sky tomorrow, they'd keep right on rolling. It would not even be a
speed bump. They don't pay for premium support. They compete to
provide premium support.*

* There are some caveats here I won't go into for confidentiality
reasons, but I can say that Azul's business model works.

> On the other side most libraries tend to move forward faster and if you
> like big ones, i'll take Spring or JakartaEE as an example - big user base
> rather than big company$ ;) - and they don't even support Java 11 anymore.

Used by big tech customers. Not so much used by big tech companies
themselves, that tend to run on stacks developed in house over more
than a decade.

-- 
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

Re: Java version for Maven 4?

[Benjamin Marwell]

> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.

Sorry that I made the wrong impression. I know this is a big effort
from personal work experience.
But it can be done. It must be done. I asked the CI team to run all CI
builds with a parallel JDK 11 build,
and they did that. This way, it was easy to see which project was not
buildable using Java 11,
so teams could work on that.

For the apps I work on, my team uses all LTS versions plus the latest
GA version (if not an LTS release).
By the way, this was an excellent recommendation by a former IBM employee.

... and that was all done without raising the language level.

Besides that, most big (tech) companies do not allow unmaintained or
unsupported software.
I am puzzled how this could work out with the state of the libraries
you mentioned.
There must be other violations in the first place, and someone allowed
them to happen.
If they hadn't been allowed to happen, there would have been no need
to catch management attention.

> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle.

I am puzzled why this would be needed. All Java 8 apps I know were
easy to build on Java 11 (with release=8)
after only very few adjustments.

That said, I do not think Apache Maven should wait for two companies
with mono-repos to update their technical debt.
It is just not justifiable for all the other users.

I agree with Gary that an EOL schedule might be our best shot here.

Am Mo., 5. Feb. 2024 um 19:56 Uhr schrieb Elliotte Rusty Harold
:
>
> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell  wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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

Re: Java version for Maven 4?

[Tamás Cservenák]

Howdy,

and sorry, I could not hold my breath...

Basically, you talk about some project somewhere that has been built with
Maven3 for the past 10 years. Fine: You can continue building it using the
same Maven3 for another 10 years, nothing stops you. But I see really
nothing, but really nothing that all this you wrote has to do with Maven4.

Again, nothing stops you to use Maven3 for another 10 years, but really. We
are not about to pull the plug on it, or whatever (as Maven4 GA is not yet
out nor will be in near future), and that pool of contributors you mention
can still freely contribute, and we will happily accept patches, as always.

/irony on
Just please pass to them, that project is under staffed, so if we get
overwhelmed count of PRs, processing may take some time.
/irony off

Thanks
T





On Mon, Feb 5, 2024 at 7:56 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell 
> wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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
>
>

Re: Java version for Maven 4?

[Romain Manni-Bucau]

Hi Elliotte,

While I share the wish 1 repo = 1 JDK, I have a hard time to see how any
company - including the ones you cite - can seriously bet on Java 11 today
for the future (not saying it wasnt hard to reach Java 11 today but we are
discussing on what we'll do tomorrow) and why it would pushback the
constraint to all the related tools.
Java 11 support is already EOL for most vendor until you go "premium"
flavor which will likely be very few people and most of them will be able
to pay somebody to backport the needed stuff in custom distro of their work
if needed anyday so not sure we should consider it.
On the other side most libraries tend to move forward faster and if you
like big ones, i'll take Spring or JakartaEE as an example - big user base
rather than big company$ ;) - and they don't even support Java 11 anymore.
So we go with Java 11 with our Maven 4 we'll likely be off most of our
users, increase potential contributors work (think PR and needed builds to
pass) without any actual gain for the project overall except maybe a few
big vendors with part of them already migrated out of maven or even
building their own build system.
I'm not sure I see it as a very weighty in the balance from my window.
So in terms of schedule - I know, the thread about EOL and maintenance got
quite closed so it will never be a thing at Maven - I think we should
embrace the future and ensure we follow main practises rather than looking
a few people cause we are about community more than companies.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 5 févr. 2024 à 19:56, Elliotte Rusty Harold  a
écrit :

> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell 
> wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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
>
>

Re: Java version for Maven 4?

[Gary Gregory]

Based on my experience, I think we (FOSS developers) can create our own
momentum by "simply" creating an EOL schedule. I have seen this EOL aspect
motivate the move away from Jetty 9 for example. Since Maven 4 is not out,
there is nothing to EOL in Maven 3 land unless you want to say that only
3.9.x is maintained and old versions are on an EOL schedule of x.

Gary

On Mon, Feb 5, 2024, 1:56 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell 
> wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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
>
>

Re: Java version for Maven 4?

[Elliotte Rusty Harold]

On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell  wrote:

> Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> no advantage of going to 11:
>

The advantage of going with 11 instead of 17 is that at least 2 really
big tech companies I could name (and who you can probably guess from
my linked in) have only recently completed their own migration to Java
11. At least one of those two companies might still employ a PMC
member (though I haven't checked post-layoffs), maybe more than one.
Both have actively supported Maven development over the years, though
that support ebbs and flows depending on corporate priorities.

I get the impression that folks who haven't worked in such large
mono-repos aren't aware of just how big a multi-year effort it is to
move a repo like that onto a new JDK version. And that's just the VM,
even before you allow devs to change the language level and start
using the new features and libraries. That's just the two really big
mono-repos I have personally worked in. I'm willing to bet that some
other big Java shops are in similar positions.

Switching back and forth between JDKs for open source development is
doable but an unnecessary hassle. I've done it before, but even
switching from JDK 8 to 11 is an extra paper cut. It kills time every
time spotless fails simply because I'm using Java 8 instead of 11.

Most importantly, it will be even harder to sell management on the
benefit of spending developer time on Maven 4 development, if it isn't
suitable for that company's own open source projects which, last I
checked, were still on Java 8. (OK, I just spot checked and the first
one I looked at is in fact still compiling for Java *1.7*, probably
because that's where their customers are).

I'm thinking back to the projects I had to justify to management a few
years and one company back, and it definitely would have been harder
then if I had to tell them what we were contributing would only work
on Java 11 or later. Maybe today I could sell them on Java 11 (or
maybe not, if they aren't paying attention to Maven at all any more)
but Java 17 would be a non-starter. They might prefer to spend their
resources on a build tool they own, or maybe just not spend the dev
hours at all.

tldr: every uptick in version requirements bleeds that many more
contributors out of the pool.

-- 
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

Re: Java version for Maven 4?

[Benjamin Marwell]

Those who need Java 8 to *run* Maven will probably not upgrade to
Maven 4 anyway, as their builds will have other problems preventing
them from upgrading.
A few third-party plugins already moved to Java 11+, thinking of spotless.

That said:

+1 Stick with 8 for Maven 3.9.x and maybe a 3.10.x (not part of this thread)
+1 to use Java 17 for Maven 4.

Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
no advantage of going to 11:

* https://endoflife.date/ibm-semeru-runtime
* https://endoflife.date/azul-zulu
* https://endoflife.date/bellsoft-liberica
* https://endoflife.date/eclipse-temurin (on par here)
* https://endoflife.date/oracle-jdk (valid for premier support, not
for extended support)

Am So., 4. Feb. 2024 um 15:01 Uhr schrieb Elliotte Rusty Harold
:
>
> If we're actually voting
>
> +1 for Java 8
> -1 for Java 17 or any later version.
>
> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
> and Google, who are stuck on older versions as a matter of policy and
> internal support.
>
> On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
>  wrote:
> >
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
> >
> >  Martin
> >
>
>
> --
> 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

Re: How to test lifecycle extension?

[tison]

Implemented in https://github.com/tisonspieces/os-detector/pull/4.

Best,
tison.

tison  于2024年2月5日周一 21:34写道：
>
> I found Maven Invoker is a component that can be used [1]. Let me try
> to make an example.
>
> Best,
> tison.
>
> [1] https://maven.apache.org/shared/maven-invoker/usage.html
>
> tison  于2024年1月25日周四 11:09写道：
> >
> > Hi,
> >
> > I'm writing a Mojo with an Extension extending
> > AbstractMavenLifecycleParticipant.
> >
> > Now, I'd like to write some tests on the extension logic. Although
> > Maven provides docs about writing tests over Mojos[1], it doesn't tell
> > how to test if an extension [2] is properly loaded and executed.
> >
> > Are there some examples of such test cases?
> >
> > Best,
> > tison.
> >
> > [1] 
> > https://maven.apache.org/plugin-developers/plugin-testing.html#using-plexustestcase
> > [2] https://maven.apache.org/guides/mini/guide-using-extensions.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How to test lifecycle extension?

[tison]

I found Maven Invoker is a component that can be used [1]. Let me try
to make an example.

Best,
tison.

[1] https://maven.apache.org/shared/maven-invoker/usage.html

tison  于2024年1月25日周四 11:09写道：
>
> Hi,
>
> I'm writing a Mojo with an Extension extending
> AbstractMavenLifecycleParticipant.
>
> Now, I'd like to write some tests on the extension logic. Although
> Maven provides docs about writing tests over Mojos[1], it doesn't tell
> how to test if an extension [2] is properly loaded and executed.
>
> Are there some examples of such test cases?
>
> Best,
> tison.
>
> [1] 
> https://maven.apache.org/plugin-developers/plugin-testing.html#using-plexustestcase
> [2] https://maven.apache.org/guides/mini/guide-using-extensions.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Java version for Maven 4?

[Xeno Amess]

I vote for kill jdk8 out as to force them upgrade to 11+

From: Tamás Cservenák 
Sent: Sunday, February 4, 2024 10:35:55 PM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

Howdy,

See Inline.

On Sun, Feb 4, 2024 at 3:01 PM Elliotte Rusty Harold 
wrote:

> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
> and Google, who are stuck on older versions as a matter of policy and
> internal support.
>
>
I see no problem here, those who are stuck with Java 8, can stick (sorry
for the pun) with Maven 3.9.x forever as well.

This thread is about Maven4, and its GA is still far away, so I see no need
for it to adapt somewhere in the unknown-how-far future (once it becomes
GA) for the sake of those who are stuck in the past.



Thanks
T



> On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
>  wrote:
> >
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
> >
> >  Martin
> >
>
>
> --
> 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
>
>