On Tue, 7 Feb 2023 at 00:46, Michael Bien <mbie...@gmail.com> wrote: > there is no default configuration for source/target yet - that was just > an idea.
I thought that was covered by this? https://github.com/apache/netbeans/blob/master/nbbuild/default.xml#L126 > again: if we can do everything in one go -> even better +1 - we're saying the same thing here. > Platform is a lib, the IDE is a tool/product. The distinction will > likely always cause some friction in runtime requirements. And platform is a cluster. Which is where some confusion is coming from I think? Additional consumers of our APIs, be it in RCP applications or other usages of our Maven libraries, are not necessarily limited to just the platform cluster. The current policy we have on this didn't special case the platform cluster as such, just that all modules requiring JDK 11 are optional (and at the time not required by the VSCode support) > Not a lot would prevent us to require JDK 21 for the IDE once it is out > some time in future (assuming tests work). But I imagine there will be > resistance to do the same for the platform. That depends what you mean? Does this again mix definitions of platform between the cluster and APIs consumed by others? We should have one approach that covers all clusters. Which doesn't mean we couldn't approach JDK 21 in a soft / optional modules way, like we're currently doing with JDK 11. There was a conversation a while back around the VSCode that included something like NetBeans as a collection of tools built on a common framework. I wonder whether we need different words here to describe the collections of APIs (framework?) and the platform cluster? > opt-ins can be trivially removed with search and replace once the > default is bumped. This shouldn't be the reason to stop an IDE module > from requiring JDK 11 for another year. > > We would have to do this anyway since there would be already opt-ins to > remove once we add a default config due to already existing modules > which require JDK 11. > > What is your concern? Why another year? I'm actually suggesting we at least try to bump everything to JDK 11 when NB 18 has branched, so in a couple of months. If anything I'm suggesting we consider bumping to JDK 17 in a year, or at least give ourselves that option. > >> No reason not to try. This is also one of the more time consuming tasks. > >> Since you have to run a full build and then check via a script that none > >> of the class files suddenly starts having their version set to 65. > >> > > Good job we have a test for that already then!here > > it is very rudimentary > > https://github.com/apache/netbeans/pull/5122#issuecomment-1359902237 I meant https://github.com/apache/netbeans/blob/master/platform/o.n.core/test/qa-functional/src/org/netbeans/core/validation/ValidateClassFilesTest.java This runs as part of commit validation IIRC - I had to update it to get our first JDK 11 compiled module PR (disco) to pass - it was hardcoded to JDK 8 before then. Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
