[MRESOLVER-408] Make master 2.0.0-SNAPSHOT #335
Conversation
pom.xml
Outdated
| <project.build.outputTimestamp>2023-09-22T18:13:46Z</project.build.outputTimestamp> | ||
| <mavenVersion>3.9.5</mavenVersion> | ||
| <minimalMavenBuildVersion>[3.8.8,)</minimalMavenBuildVersion> | ||
| <minimalJavaBuildVersion>[17.0.6,)</minimalJavaBuildVersion> |
There was a problem hiding this comment.
What is the benefit to require Java 17 to build it? Why is 11 not enough?
There was a problem hiding this comment.
IMHO next to last LTS is good compromise for build time requirement for our anyway dated stack we use. In other words, I want to encourage experiments, and am willing even to go for Java 21 but there are some spotless issues (@slawekjaranowski plz help). Also, I must emphasize: most resolver modules will be still release=8 compiled, but probably not all. As we may have new modules, that do want all the new nice things we can get.
Am pretty much sure, that our users run Maven on latest Java versions (unlike "aligners"), so as resolver being one of the Maven fundamentals libraries, let's make a leap here.
There was a problem hiding this comment.
Issue with spotless fix by workaround in parent apache/maven-parent#135
There was a problem hiding this comment.
I still don't see a reason to artificially limit this. You still can build with newer ones.
There was a problem hiding this comment.
It is limit only for minimum - you can build by newer versions.
There was a problem hiding this comment.
There ARE technical (and human) justifications. For example, remember this thread? 😄
https://lists.apache.org/thread/k5sc3w7w4xkgjfzyxxltg06722dvspk7
In short, we tend to say "Java 8" but there are important Java updates, hence there is java 8u172 from 2018 and Java 8u371 from 2023. This thread happened to us, and clearly shows there is sense to set "lower limit". I just dont want to waste my time and resources on things like happened in that thread anymore.
This limit simply says (and means) "recent Java 17" and NOT "just any java 17" as we used to say so far. This is far better, explicit, and even the error message makes sense as shown here:
https://lists.apache.org/thread/tz4qfqhvrvf2fr84l8loqsfpmcf5poz4
There was a problem hiding this comment.
I can, but why would I? I want to add modules that do HTTP/2, and require Java11+, moreover, for testing those I may want to use dependencies (test scoped) that are Java17...
What would limiting build time Java requirement to 8u300 help with those above?
There was a problem hiding this comment.
Do you have Java 17 test deps already?
There was a problem hiding this comment.
Imho, I would keep it as low as needed, but certainly would not put any barrier in raising the build time requirement. This would allow using multi-release JARs if needed or even leverage new JEP such as FFM (for accessing native code or memory). Whatever is needed at build time should be fine.
Using Java 17 and 21
* sisu was invoked twice * compiler: we do not use annotation processors (while Sisu APT is present, so we do not want it auto-picked up) * compiler: be explicit about deprecations (to help us removing that cruft)
cstamas
changed the title
Changes:
release=8https://issues.apache.org/jira/browse/MRESOLVER-408