Re: [DISCUSS] Java version for Maven
It has been mentioned before, but just to add, since the bytecode level is IMHO the smallest problem: Jorge Solórzano wrote on 25. Feb 2024 00:41 (GMT +01:00): > you can use JDK 17 to produce Java 8 bytecode using Java 8 > features, that is the distinction I made between runtime and build time, > but it looks it's still not clear. In the past a newer JDK version could compile for an older Bytecode version and compatible with the source code constructs, BUT it used its own classlibrary which had usually different method and therefore create NON-compat results. For that reason you had to provide the old bootpath if you wanted a clean build (or, since this Is nearly the same work than just using the old JDK always use the same build/target Version, this was very typical for java7 builds and many think it is needed for 8 as well). But, this is no longer a problem since Java9, the new -release option does not only simplify -source and -target into a single option it additionally makes the Java compiler use an internal list of approved JCL signatures, therefore being save for cross compile (only If you switch to the new flag). Unfortunatelly -release 8 has still problems with removed libraries, so it is a bit of a work to use newer JDKs to compile old codebase (not a drop-in in some cases like jaxb). Btw Java8 POMs are a bit annoying since you can’t build them on Java 8 With maven.compiler.release and you can’t (should not) build them on 9+ with maven.compiler.target. Luckily you can solve that with a profile activated by runtime version. https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html Gruß Bernd — https://bernd.eckenfels.net - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
On Sat, Feb 24, 2024, 17:24 Hunter C Payne wrote: > Is a JDK 17 capable of building JDK 8 jars from JDK 17 source? No, it doesn't, you can use JDK 17 to produce Java 8 bytecode using Java 8 features, that is the distinction I made between runtime and build time, but it looks it's still not clear. To use Java 17 features, you need to produce Java 17 bytecode, and that requires at least Java 17 as runtime. If so, what are we discussing/arguing/debating about? Seems to me that > that configuration gets you everything you want without forcing Maven 4 to > not work with JVM/JRE 8. > Hunter > > On Saturday, February 24, 2024 at 03:09:07 PM PST, Jorge Solórzano < > jor...@gmail.com> wrote: > > On Sat, Feb 24, 2024, 16:55 Tamás Cservenák wrote: > > > Jorge, > > > > Allow me one question: why would we need 3.10 for this? Could not we set > > same thing for existing 3.9.x? > > > > Yes, but 3.10 can be used to better signal that is an LTS since the > beginning and will only contain critical bug fixes, breaking change should > not happen, in other words, that's not actively worked on and will be the > last version of the 3.x line. > > Other than that, if it's agreed to just use 3.9 as LTS, then simply > s/3.10/3.9/ on the previous mail. :) > > > > > > > T > > > > > > > > > > On Sat, Feb 24, 2024, 23:43 Jorge Solórzano wrote: > > > > > Hi Maven Developers, > > > > > > A lot has been told already from both sides, but please, please, let's > > > focus on how to improve the current status and define how and what Java > > > version will be required for Maven, not on trivial discussions about > > using > > > var or virtual threads. > > > > > > Most developers would love to use the latest and greatest JDK, while > > > Enterprises want stability for deployments, here, we need to change the > > > mindset as the OpenJDK release cadence is not going to slow down. > > > > > > The Java ecosystem is moving forward and Maven should not get stuck > with > > a > > > 10 years old JDK version. > > > > > > There are many trade-offs from both sides, many complaints, and (sorry > to > > > be harsh) many absurd arguments for being stuck until 2030 with Java 8. > > > > > > I don't want to fall into the trap of "since I use it this way, I'm > > correct > > > and you don't ", so I will try to be as impartial as possible, I do > agree > > > there is a need to support a Maven compatible with Java 8, I also do > > agree > > > that developers would like to use latest JDK features on Maven > > > core/plugins, so there needs to be a middle ground. > > > > > > First, we need to distinguish the difference between the required Java > > > version used at RUNTIME vs the Java version used at BUILD TIME, anyone > > can > > > compile a Java project at build time using Java 21 and target Java 8, > so > > > here the issue is not about using Java 9+ (11, 17, 21) to compile code > > that > > > will be used at runtime in Java 8, and if every project makes uses of > the > > > --release option of java compiler, there will be no issues as we are > > simply > > > targeting to Java 8, it doesn't matter if you compile with Java > 11/17/21 > > > if, in the end, the produced bytecode is Java 8 compatible. What we are > > > talking about here is the Java version required at RUNTIME, meaning > that > > if > > > we raise the Java version to something like Java 17, it will not work > > with > > > Java 11 or 8, with that point being clear, let's continue. > > > > > > Before my proposal, a little disclaimer: I'm just an occasional > > > contributor, not a committer or Maven PMC, and while would be great to > > have > > > a full-time job to work on Maven, is currently not my case. > > > > > > So, the proposal that could make everyone happy is this: > > > > > > This proposal suggests the introduction of a *Long-Term Support (LTS)* > > > version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting* > > > Java 17.* > > > > > > In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the > > same > > > day that Maven 4.0 is released, cut and release a version of Maven > > 3.10.0, > > > this version (3.10.x) will be marked as LTS, and "supported" for up to > 3 > > or > > > 5 years (depending on needs) with only security or critical bug fixes, > > this > > > means that any new feature won't be backported to the 3.10.x branch, > > > something like supporting a new JDK version (like Java 25) will be > added > > to > > > Maven 4. > > > > > > Why Java 17 and not Java 21? To be conservative and have a wider > > audience, > > > this should not be taken as a set-in-stone version, and if in 2 or 3 > > years > > > the Java ecosystem has moved fast enough, then a Maven version that > > targets > > > Java 21 or Java 25 should be possible in something like Maven 4.2 (or > > > whatever version is released to that date), and when the current 3.10.x > > > version "expires" in 3 or 5 years, mark a new LTS version rinse, and > > > repeat. > > > > > > *Advantages
Re: [DISCUSS] Java version for Maven
Is a JDK 17 capable of building JDK 8 jars from JDK 17 source? If so, what are we discussing/arguing/debating about? Seems to me that that configuration gets you everything you want without forcing Maven 4 to not work with JVM/JRE 8. Hunter On Saturday, February 24, 2024 at 03:09:07 PM PST, Jorge Solórzano wrote: On Sat, Feb 24, 2024, 16:55 Tamás Cservenák wrote: > Jorge, > > Allow me one question: why would we need 3.10 for this? Could not we set > same thing for existing 3.9.x? > Yes, but 3.10 can be used to better signal that is an LTS since the beginning and will only contain critical bug fixes, breaking change should not happen, in other words, that's not actively worked on and will be the last version of the 3.x line. Other than that, if it's agreed to just use 3.9 as LTS, then simply s/3.10/3.9/ on the previous mail. :) > T > > > > > On Sat, Feb 24, 2024, 23:43 Jorge Solórzano wrote: > > > Hi Maven Developers, > > > > A lot has been told already from both sides, but please, please, let's > > focus on how to improve the current status and define how and what Java > > version will be required for Maven, not on trivial discussions about > using > > var or virtual threads. > > > > Most developers would love to use the latest and greatest JDK, while > > Enterprises want stability for deployments, here, we need to change the > > mindset as the OpenJDK release cadence is not going to slow down. > > > > The Java ecosystem is moving forward and Maven should not get stuck with > a > > 10 years old JDK version. > > > > There are many trade-offs from both sides, many complaints, and (sorry to > > be harsh) many absurd arguments for being stuck until 2030 with Java 8. > > > > I don't want to fall into the trap of "since I use it this way, I'm > correct > > and you don't ", so I will try to be as impartial as possible, I do agree > > there is a need to support a Maven compatible with Java 8, I also do > agree > > that developers would like to use latest JDK features on Maven > > core/plugins, so there needs to be a middle ground. > > > > First, we need to distinguish the difference between the required Java > > version used at RUNTIME vs the Java version used at BUILD TIME, anyone > can > > compile a Java project at build time using Java 21 and target Java 8, so > > here the issue is not about using Java 9+ (11, 17, 21) to compile code > that > > will be used at runtime in Java 8, and if every project makes uses of the > > --release option of java compiler, there will be no issues as we are > simply > > targeting to Java 8, it doesn't matter if you compile with Java 11/17/21 > > if, in the end, the produced bytecode is Java 8 compatible. What we are > > talking about here is the Java version required at RUNTIME, meaning that > if > > we raise the Java version to something like Java 17, it will not work > with > > Java 11 or 8, with that point being clear, let's continue. > > > > Before my proposal, a little disclaimer: I'm just an occasional > > contributor, not a committer or Maven PMC, and while would be great to > have > > a full-time job to work on Maven, is currently not my case. > > > > So, the proposal that could make everyone happy is this: > > > > This proposal suggests the introduction of a *Long-Term Support (LTS)* > > version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting* > > Java 17.* > > > > In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the > same > > day that Maven 4.0 is released, cut and release a version of Maven > 3.10.0, > > this version (3.10.x) will be marked as LTS, and "supported" for up to 3 > or > > 5 years (depending on needs) with only security or critical bug fixes, > this > > means that any new feature won't be backported to the 3.10.x branch, > > something like supporting a new JDK version (like Java 25) will be added > to > > Maven 4. > > > > Why Java 17 and not Java 21? To be conservative and have a wider > audience, > > this should not be taken as a set-in-stone version, and if in 2 or 3 > years > > the Java ecosystem has moved fast enough, then a Maven version that > targets > > Java 21 or Java 25 should be possible in something like Maven 4.2 (or > > whatever version is released to that date), and when the current 3.10.x > > version "expires" in 3 or 5 years, mark a new LTS version rinse, and > > repeat. > > > > *Advantages of Maven 3.10.x (Targeting Java 8):* > > > > 1. > > > > *Stability and Compatibility:* Maven 3.10.x will provide stability and > > compatibility for projects still reliant on Java 8. Many enterprises > and > > legacy projects continue to utilize Java 8 due to its stability and > > extensive support. By maintaining a Maven version specifically for > Java > > 8, > > these projects can benefit from ongoing support without being forced > to > > migrate to newer Java versions prematurely. > > 2. > > > > *Extended Support Period:* As an LTS version, Maven 3.10.x will > rece
Re: [DISCUSS] Java version for Maven
On Sat, Feb 24, 2024, 16:55 Tamás Cservenák wrote: > Jorge, > > Allow me one question: why would we need 3.10 for this? Could not we set > same thing for existing 3.9.x? > Yes, but 3.10 can be used to better signal that is an LTS since the beginning and will only contain critical bug fixes, breaking change should not happen, in other words, that's not actively worked on and will be the last version of the 3.x line. Other than that, if it's agreed to just use 3.9 as LTS, then simply s/3.10/3.9/ on the previous mail. :) > T > > > > > On Sat, Feb 24, 2024, 23:43 Jorge Solórzano wrote: > > > Hi Maven Developers, > > > > A lot has been told already from both sides, but please, please, let's > > focus on how to improve the current status and define how and what Java > > version will be required for Maven, not on trivial discussions about > using > > var or virtual threads. > > > > Most developers would love to use the latest and greatest JDK, while > > Enterprises want stability for deployments, here, we need to change the > > mindset as the OpenJDK release cadence is not going to slow down. > > > > The Java ecosystem is moving forward and Maven should not get stuck with > a > > 10 years old JDK version. > > > > There are many trade-offs from both sides, many complaints, and (sorry to > > be harsh) many absurd arguments for being stuck until 2030 with Java 8. > > > > I don't want to fall into the trap of "since I use it this way, I'm > correct > > and you don't ", so I will try to be as impartial as possible, I do agree > > there is a need to support a Maven compatible with Java 8, I also do > agree > > that developers would like to use latest JDK features on Maven > > core/plugins, so there needs to be a middle ground. > > > > First, we need to distinguish the difference between the required Java > > version used at RUNTIME vs the Java version used at BUILD TIME, anyone > can > > compile a Java project at build time using Java 21 and target Java 8, so > > here the issue is not about using Java 9+ (11, 17, 21) to compile code > that > > will be used at runtime in Java 8, and if every project makes uses of the > > --release option of java compiler, there will be no issues as we are > simply > > targeting to Java 8, it doesn't matter if you compile with Java 11/17/21 > > if, in the end, the produced bytecode is Java 8 compatible. What we are > > talking about here is the Java version required at RUNTIME, meaning that > if > > we raise the Java version to something like Java 17, it will not work > with > > Java 11 or 8, with that point being clear, let's continue. > > > > Before my proposal, a little disclaimer: I'm just an occasional > > contributor, not a committer or Maven PMC, and while would be great to > have > > a full-time job to work on Maven, is currently not my case. > > > > So, the proposal that could make everyone happy is this: > > > > This proposal suggests the introduction of a *Long-Term Support (LTS)* > > version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting* > > Java 17.* > > > > In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the > same > > day that Maven 4.0 is released, cut and release a version of Maven > 3.10.0, > > this version (3.10.x) will be marked as LTS, and "supported" for up to 3 > or > > 5 years (depending on needs) with only security or critical bug fixes, > this > > means that any new feature won't be backported to the 3.10.x branch, > > something like supporting a new JDK version (like Java 25) will be added > to > > Maven 4. > > > > Why Java 17 and not Java 21? To be conservative and have a wider > audience, > > this should not be taken as a set-in-stone version, and if in 2 or 3 > years > > the Java ecosystem has moved fast enough, then a Maven version that > targets > > Java 21 or Java 25 should be possible in something like Maven 4.2 (or > > whatever version is released to that date), and when the current 3.10.x > > version "expires" in 3 or 5 years, mark a new LTS version rinse, and > > repeat. > > > > *Advantages of Maven 3.10.x (Targeting Java 8):* > > > >1. > > > >*Stability and Compatibility:* Maven 3.10.x will provide stability and > >compatibility for projects still reliant on Java 8. Many enterprises > and > >legacy projects continue to utilize Java 8 due to its stability and > >extensive support. By maintaining a Maven version specifically for > Java > > 8, > >these projects can benefit from ongoing support without being forced > to > >migrate to newer Java versions prematurely. > >2. > > > >*Extended Support Period:* As an LTS version, Maven 3.10.x will > receive > >extended support and bug fixes, ensuring reliability for projects in > >production environments. This extended support period is crucial for > >enterprises with long-term projects that require stability and minimal > >disruption. > >3. > > > >*Security Patches:* Security vulnerabilities are a signifi
Re: [DISCUSS] Java version for Maven
Hello, thanks Jorge I fully support your summary. want to bring an additional points in support for newer runtime Java: Because Maven alone isn’t the complete ecosystem and many other tools have higher requirements already. Fr example both Jenkins (maven-style jobs) as well as SonarQube scanner plugins can’t be used with Java 8 anymore. And yes such a shift was not only for those big tech-Gigants which are stuck on Java8 a pain, but also for many other users - but this is in the past. Most have migrated to be finally able to use the -release option as a quality of life improvement even though they have to target Java 8 Bytecode level. I think there is absolutely no problem to move along with a new major version of maven, in fact it’s the only sane moment to do so. I am sure many plug-in authors are eager to raise their minimum version just to be able to use new external technologies. And if the whole ecosystem understands there is a 3.d and 4.x branch, the better… Gruss Bernd Jorge Solórzano wrote on 24. Feb 2024 23:42 (GMT +01:00): > Hi Maven Developers, > > A lot has been told already from both sides, but please, please, let's > focus on how to improve the current status and define how and what Java > version will be required for Maven, not on trivial discussions about using > var or virtual threads. — https://bernd.eckenfels.net - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
Jorge, Allow me one question: why would we need 3.10 for this? Could not we set same thing for existing 3.9.x? T On Sat, Feb 24, 2024, 23:43 Jorge Solórzano wrote: > Hi Maven Developers, > > A lot has been told already from both sides, but please, please, let's > focus on how to improve the current status and define how and what Java > version will be required for Maven, not on trivial discussions about using > var or virtual threads. > > Most developers would love to use the latest and greatest JDK, while > Enterprises want stability for deployments, here, we need to change the > mindset as the OpenJDK release cadence is not going to slow down. > > The Java ecosystem is moving forward and Maven should not get stuck with a > 10 years old JDK version. > > There are many trade-offs from both sides, many complaints, and (sorry to > be harsh) many absurd arguments for being stuck until 2030 with Java 8. > > I don't want to fall into the trap of "since I use it this way, I'm correct > and you don't ", so I will try to be as impartial as possible, I do agree > there is a need to support a Maven compatible with Java 8, I also do agree > that developers would like to use latest JDK features on Maven > core/plugins, so there needs to be a middle ground. > > First, we need to distinguish the difference between the required Java > version used at RUNTIME vs the Java version used at BUILD TIME, anyone can > compile a Java project at build time using Java 21 and target Java 8, so > here the issue is not about using Java 9+ (11, 17, 21) to compile code that > will be used at runtime in Java 8, and if every project makes uses of the > --release option of java compiler, there will be no issues as we are simply > targeting to Java 8, it doesn't matter if you compile with Java 11/17/21 > if, in the end, the produced bytecode is Java 8 compatible. What we are > talking about here is the Java version required at RUNTIME, meaning that if > we raise the Java version to something like Java 17, it will not work with > Java 11 or 8, with that point being clear, let's continue. > > Before my proposal, a little disclaimer: I'm just an occasional > contributor, not a committer or Maven PMC, and while would be great to have > a full-time job to work on Maven, is currently not my case. > > So, the proposal that could make everyone happy is this: > > This proposal suggests the introduction of a *Long-Term Support (LTS)* > version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting* > Java 17.* > > In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the same > day that Maven 4.0 is released, cut and release a version of Maven 3.10.0, > this version (3.10.x) will be marked as LTS, and "supported" for up to 3 or > 5 years (depending on needs) with only security or critical bug fixes, this > means that any new feature won't be backported to the 3.10.x branch, > something like supporting a new JDK version (like Java 25) will be added to > Maven 4. > > Why Java 17 and not Java 21? To be conservative and have a wider audience, > this should not be taken as a set-in-stone version, and if in 2 or 3 years > the Java ecosystem has moved fast enough, then a Maven version that targets > Java 21 or Java 25 should be possible in something like Maven 4.2 (or > whatever version is released to that date), and when the current 3.10.x > version "expires" in 3 or 5 years, mark a new LTS version rinse, and > repeat. > > *Advantages of Maven 3.10.x (Targeting Java 8):* > >1. > >*Stability and Compatibility:* Maven 3.10.x will provide stability and >compatibility for projects still reliant on Java 8. Many enterprises and >legacy projects continue to utilize Java 8 due to its stability and >extensive support. By maintaining a Maven version specifically for Java > 8, >these projects can benefit from ongoing support without being forced to >migrate to newer Java versions prematurely. >2. > >*Extended Support Period:* As an LTS version, Maven 3.10.x will receive >extended support and bug fixes, ensuring reliability for projects in >production environments. This extended support period is crucial for >enterprises with long-term projects that require stability and minimal >disruption. >3. > >*Security Patches:* Security vulnerabilities are a significant concern >for software projects. With an LTS version like Maven 3.10.x, users can >expect timely security patches to address any potential vulnerabilities, >thus enhancing the overall security posture of their projects. >4. > >*Maintaining Legacy Codebases:* Many organizations have substantial >investments in legacy codebases built on Java 8. Maven 3.10.x enables > these >organizations to continue maintaining and evolving their existing > projects >without the need for an immediate migration to newer Java versions, >reducing migration overheads and risks. > > *Advantages of Maven 4.0 (Targe
Re: [DISCUSS] Java version for Maven
Hi Maven Developers, A lot has been told already from both sides, but please, please, let's focus on how to improve the current status and define how and what Java version will be required for Maven, not on trivial discussions about using var or virtual threads. Most developers would love to use the latest and greatest JDK, while Enterprises want stability for deployments, here, we need to change the mindset as the OpenJDK release cadence is not going to slow down. The Java ecosystem is moving forward and Maven should not get stuck with a 10 years old JDK version. There are many trade-offs from both sides, many complaints, and (sorry to be harsh) many absurd arguments for being stuck until 2030 with Java 8. I don't want to fall into the trap of "since I use it this way, I'm correct and you don't ", so I will try to be as impartial as possible, I do agree there is a need to support a Maven compatible with Java 8, I also do agree that developers would like to use latest JDK features on Maven core/plugins, so there needs to be a middle ground. First, we need to distinguish the difference between the required Java version used at RUNTIME vs the Java version used at BUILD TIME, anyone can compile a Java project at build time using Java 21 and target Java 8, so here the issue is not about using Java 9+ (11, 17, 21) to compile code that will be used at runtime in Java 8, and if every project makes uses of the --release option of java compiler, there will be no issues as we are simply targeting to Java 8, it doesn't matter if you compile with Java 11/17/21 if, in the end, the produced bytecode is Java 8 compatible. What we are talking about here is the Java version required at RUNTIME, meaning that if we raise the Java version to something like Java 17, it will not work with Java 11 or 8, with that point being clear, let's continue. Before my proposal, a little disclaimer: I'm just an occasional contributor, not a committer or Maven PMC, and while would be great to have a full-time job to work on Maven, is currently not my case. So, the proposal that could make everyone happy is this: This proposal suggests the introduction of a *Long-Term Support (LTS)* version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting* Java 17.* In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the same day that Maven 4.0 is released, cut and release a version of Maven 3.10.0, this version (3.10.x) will be marked as LTS, and "supported" for up to 3 or 5 years (depending on needs) with only security or critical bug fixes, this means that any new feature won't be backported to the 3.10.x branch, something like supporting a new JDK version (like Java 25) will be added to Maven 4. Why Java 17 and not Java 21? To be conservative and have a wider audience, this should not be taken as a set-in-stone version, and if in 2 or 3 years the Java ecosystem has moved fast enough, then a Maven version that targets Java 21 or Java 25 should be possible in something like Maven 4.2 (or whatever version is released to that date), and when the current 3.10.x version "expires" in 3 or 5 years, mark a new LTS version rinse, and repeat. *Advantages of Maven 3.10.x (Targeting Java 8):* 1. *Stability and Compatibility:* Maven 3.10.x will provide stability and compatibility for projects still reliant on Java 8. Many enterprises and legacy projects continue to utilize Java 8 due to its stability and extensive support. By maintaining a Maven version specifically for Java 8, these projects can benefit from ongoing support without being forced to migrate to newer Java versions prematurely. 2. *Extended Support Period:* As an LTS version, Maven 3.10.x will receive extended support and bug fixes, ensuring reliability for projects in production environments. This extended support period is crucial for enterprises with long-term projects that require stability and minimal disruption. 3. *Security Patches:* Security vulnerabilities are a significant concern for software projects. With an LTS version like Maven 3.10.x, users can expect timely security patches to address any potential vulnerabilities, thus enhancing the overall security posture of their projects. 4. *Maintaining Legacy Codebases:* Many organizations have substantial investments in legacy codebases built on Java 8. Maven 3.10.x enables these organizations to continue maintaining and evolving their existing projects without the need for an immediate migration to newer Java versions, reducing migration overheads and risks. *Advantages of Maven 4.0 (Targeting Java 17):* 1. *Compatibility with Latest Java Features:* Maven 4.0 targeting Java 17 will empower developers to leverage the latest features and enhancements introduced in newer Java versions. This compatibility fosters innovation and enables developers to build modern, high-performance applications. 2. *Performance
Re: [VOTE] Release Maven Resolver 2.0.0-alpha-8
+1 sob., 24 lut 2024, 14:50 użytkownik Slawomir Jaranowski < s.jaranow...@gmail.com> napisał: > +1 > > czw., 22 lut 2024 o 17:29 Tamás Cservenák > napisał(a): > > > Howdy, > > > > Note: This is a seventh (alpha-4 was scrubbed) preview release of > Resolver > > 2.0.0, that would allow any downstream consumers to try it out and adapt. > > The supplier is aligned with Maven 4.0.0-alpha-12. > > > > For configuration changes, see > > > > > https://maven.apache.org/resolver-archives/resolver-LATEST/configuration.html > > > > IF the vote is successful, the staging site will NOT be moved to > > https://maven.apache.org/resolver/ but instead will be made reachable > from > > https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-8/ only. > > > > The 1.9.18 is still the "latest stable" release of Maven Resolver. > > > > === > > > > We solved 16 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354186 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-2066/ > > > > Source release SHA512: > > > > > 0b6056dea2698eb9c06bb1b12f682e4341def46194337802da147ded7062558446c9d35fafd93537a86c1ea13bf40b4c40c05f901cf8035bb705a65281c4077e > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > -- > Sławomir Jaranowski >
Re: Hand ups - new releases in next week
Thanks. This is helpful. On Sat, Feb 24, 2024 at 1:44 PM Slawomir Jaranowski wrote: > > Hi, > > I'm going to release at the end of next week: > > 1. maven-assembly-plugin > > issues for next release: > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317220%20AND%20fixVersion%20%3D%2012353243%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC > open issues: https://issues.apache.org/jira/projects/MASSEMBLY > open PRs: https://github.com/apache/maven-compiler-plugin/pulls > > 2. plexus-compiler > > fixes: > https://github.com/codehaus-plexus/plexus-compiler/compare/plexus-compiler-2.14.2...refs/heads/master > open issues: https://github.com/codehaus-plexus/plexus-compiler/issues > open PRs in: https://github.com/codehaus-plexus/plexus-compiler/pulls > > 2. maven-compiler-plugin > > issues for next release: > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20fixVersion%20%3D%2012354079%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC > open issues: https://issues.apache.org/jira/projects/MCOMPILER > open PRs: https://github.com/apache/maven-compiler-plugin/pulls > > 3. maven-jar-plugin > > issues for next release: > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317526%20AND%20fixVersion%20%3D%2012352303%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC > open issues: https://issues.apache.org/jira/projects/MJAR > open PRs: https://github.com/apache/maven-jar-plugin/pulls > > So any help will be appreciated with: > > - check or comments opened issues - maybe some more can be fixed > - review opened PR - many times review from contributors and users are very > valuable > - check documentation - sometime we can fix a simple misspells, broken > links, clarify a more bit and so on > > All contributors are welcome - old and new ones with helping on preparing > the new release. > > -- > Sławomir Jaranowski -- 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: [VOTE] Release Maven Resolver 2.0.0-alpha-8
+1 czw., 22 lut 2024 o 17:29 Tamás Cservenák napisał(a): > Howdy, > > Note: This is a seventh (alpha-4 was scrubbed) preview release of Resolver > 2.0.0, that would allow any downstream consumers to try it out and adapt. > The supplier is aligned with Maven 4.0.0-alpha-12. > > For configuration changes, see > > https://maven.apache.org/resolver-archives/resolver-LATEST/configuration.html > > IF the vote is successful, the staging site will NOT be moved to > https://maven.apache.org/resolver/ but instead will be made reachable from > https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-8/ only. > > The 1.9.18 is still the "latest stable" release of Maven Resolver. > > === > > We solved 16 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12354186 > > There are still some issues in JIRA: > https://issues.apache.org/jira/projects/MRESOLVER/issues > > Staging repository: > https://repository.apache.org/content/repositories/maven-2066/ > > Source release SHA512: > > 0b6056dea2698eb9c06bb1b12f682e4341def46194337802da147ded7062558446c9d35fafd93537a86c1ea13bf40b4c40c05f901cf8035bb705a65281c4077e > > Staging site: > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > -- Sławomir Jaranowski
Hand ups - new releases in next week
Hi, I'm going to release at the end of next week: 1. maven-assembly-plugin issues for next release: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317220%20AND%20fixVersion%20%3D%2012353243%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC open issues: https://issues.apache.org/jira/projects/MASSEMBLY open PRs: https://github.com/apache/maven-compiler-plugin/pulls 2. plexus-compiler fixes: https://github.com/codehaus-plexus/plexus-compiler/compare/plexus-compiler-2.14.2...refs/heads/master open issues: https://github.com/codehaus-plexus/plexus-compiler/issues open PRs in: https://github.com/codehaus-plexus/plexus-compiler/pulls 2. maven-compiler-plugin issues for next release: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20fixVersion%20%3D%2012354079%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC open issues: https://issues.apache.org/jira/projects/MCOMPILER open PRs: https://github.com/apache/maven-compiler-plugin/pulls 3. maven-jar-plugin issues for next release: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317526%20AND%20fixVersion%20%3D%2012352303%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC open issues: https://issues.apache.org/jira/projects/MJAR open PRs: https://github.com/apache/maven-jar-plugin/pulls So any help will be appreciated with: - check or comments opened issues - maybe some more can be fixed - review opened PR - many times review from contributors and users are very valuable - check documentation - sometime we can fix a simple misspells, broken links, clarify a more bit and so on All contributors are welcome - old and new ones with helping on preparing the new release. -- Sławomir Jaranowski
