j2ee: Centralize {Java, Jakarta} EE specification

[asbachb]

Today we have a {Java, Jakarta} EE Profile which contains information about the release version and the profile (web, full). As NetBeans is able to create certain files like web.xml we need to have a template which contain schema information based on the {Java, Jakarta} EE specification.
Since prior to #5970 the profiles were String based most of the classes relying on that information introduced if/else statements which are extended on every {Java, Jakarta} EE release.

So basically my idea is to put more information about a {Java, Jakarta} EE profile into the Profile class itself. So the idea is to provide the {Java, Jakarta} EE specification in code so that the modules can access these information.

My goal is to:

• Ease the efforts todo when a new Jakarta EE release is published
• Get rid of these long if/else statements

To get a better idea what I'm talking about I already implemented a poc.

@mbien What do you think: Should I proceed with the other deployment descriptors or do you dislike the idea?

[mbien]

What do you think: Should I proceed with the other deployment descriptors or do you dislike the idea?

I like what I see so far. Unfortunately some of the enterprise tests can't run on JDK 11 yet #4904, so using JDK 11 API is blocked for now. You would also have to set source/target to 11 and add OpenIDE-Module-Java-Dependencies: Java > 11 to the module manifest which has to be tested to check if this doesn't cause any fallout.

Getting rid of the if/else chains by improving the data structures a bit is much appreciated.

[asbachb]

What do you think: Should I proceed with the other deployment descriptors or do you dislike the idea?

I like what I see so far. Unfortunately some of the enterprise tests can't run on JDK 11 yet #4904, so using JDK 11 API is blocked for now. You would also have to set source/target to 11 and add OpenIDE-Module-Java-Dependencies: Java > 11 to the module manifest which has to be tested to check if this doesn't cause any fallout.

Getting rid of the if/else chains by improving the data structures a bit is much appreciated.

Thanks for your response.

I'm aware that it does not work out for now. Just wanted to fetch some feedback before putting more time into to sort things out you mentioned.

[asbachb]

I guess before I progress it would be better to review this one if I'm heading in the right direction.
If I understand you correctly @mbien currently we could not merge this due to #4904 ?

[mbien]

currently we could not merge this due to 4904

yes I am a bit worried about that one. Would be good to add the JDK 11 requirement to the module manifest like:
https://github.com/search?q=repo%3Aapache%2Fnetbeans+%22OpenIDE-Module-Java-Dependencies%3A+Java+%3E+11%22&type=code

Then we can do a test run with all tests enabled. I am curious what else will fail outside of the enterprise job.

[asbachb]

currently we could not merge this due to 4904

yes I am a bit worried about that one. Would be good to add the JDK 11 requirement to the module manifest like: https://github.com/search?q=repo%3Aapache%2Fnetbeans+%22OpenIDE-Module-Java-Dependencies%3A+Java+%3E+11%22&type=code

Then we can do a test run with all tests enabled. I am curious what else will fail outside of the enterprise job.

Are you talking about j2ee.core or all je22 modules?

[asbachb]

As discussed on Slack: Reverted back to Java Source Target 8 as #4904 most likely take some more time.

[mbien]

testModulesForCL: org.netbeans.junit.NbModuleSuiteTest
and
testModulesForMe: org.netbeans.junit.NbModuleSuiteTest
Needs adjustment since it is currently failing. The assert message confuses me a bit since it is probably out of date.

Four modules left: should be probably Five modules expected: ? (now six I suppose)

[mbien]

lets move this to NB20 so that we don't have to rush it in before freeze. Cleanups are better applied early in the cycle anyway.

[mbien]

hmm. whats up with that latte test lol.

[asbachb]

It's weird. Especially only windows build is failing.

[asbachb]

Yesterday I managed to get this reprocuded somehow (which I failed today).

Yesterday it seemed that the classpath argument which was constructed when launching the tests was too long because of the new classpath entries:

Caused by: java.io.IOException: Cannot run program "C:\Program Files\Eclipse Adoptium\jdk-17.0.7.7-hotspot\bin\java.exe" (in directory "C:\Dev\src\netbeans\php\php.latte"): CreateProcess error=206, The filename or extension is too long
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
	at java.base/java.lang.Runtime.exec(Runtime.java:594)
	at org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58)
	at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:424)
	at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:438)
	at org.apache.tools.ant.taskdefs.Java.fork(Java.java:881)
	... 92 more
Caused by: java.io.IOException: CreateProcess error=206, The filename or extension is too long
	at java.base/java.lang.ProcessImpl.create(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:499)
	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:158)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
	... 98 more

I just wonder why mockito is passed as classpath requirement to run the php tests...

[asbachb]

Ok this can be reproduced when putting the NetBeans sources into C:\a\netbeans\netbeans as the github action does. Then the path is too long for ant to create the java process running the tests.

[asbachb]

I guess I'm a little bit stuck:

So from my understanding a workaround could be to generate a jar with the classpath in `manifest.mf`` and pass that jar instead of all module dependencies, but I failed to write a task accomplishing that...

[mbien]

I just wonder why mockito is passed as classpath requirement to run the php tests...

possibly because it is now a dependency of nbunit? see harness/nbjunit/nbproject/project.xml

I guess I'm a little bit stuck:

it should be possible to put arguments into "argfiles" for most if not all java tools by now, e.g:
https://bugs.openjdk.org/browse/JDK-8027634
Its a single arg pointing at a file which stores one arg per line

But maybe this can be also solved by reducing the dependencies..., a huge cp could be a red flag in itself.

If this is too much work I would investigate if this can be solved without mockito. I wouldn't put too much time into the ant build.

[matthiasblaesing]

Removed milestone as now work was done after last milestone move.