WTP's Requirements

[merks]

@nitind

Rather than create a WTP Bugzilla, I thought I'd create an issue here, for discussion...

I created a new setup for all of WTP. I tried to clone the aggregator as well as recursively the submodules:

Then I used a targlet task to import all projects from all those clones, which is a bit of a disastrous mess of very old "crap", so I gradually refined it to filter things down to a more sensible subset:

Originally I used a targlet without specifying that all requirements must resolve, and then I gradually worked to eliminate errors and to use only stuff from https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/nightly/latest/ (though I have a locally build of it because I had to add a few things for WTP). Some projects are so old they don't even have a MANIFEST.MF and rather specify that information via an ancient style plugin.xml.

Now I have a bunch of changes for allowing newer versions and for using newer bundle symbolic names, e.g.,

Eventually I ended up with a subset of things that are error free and for which all dependencies resolve. From that I can generate a *.target like the attached:

wtp.target.txt

But I'm not sure where to go forward from this point.

I don't get the sense that WTP is in maintainable state in the current form. There is too much stuff that seems no longer used and that just causes confusion. There are projects that are maybe still important, but one can't work with them in an error-free workspace to update them properly.

It seems to me that there needs to be some type of automated setup that clones the appropriate git repositories (which all need to migrate to GitHub), imports only the relevant projects, and ultimately produces an error free workspace. Currently I have a very crude prototype for that, along with a rather substantial set of untested changes...

---

I noticed the following /org.eclipse.wst.xsl.feature/feature.xml and wonder if that's needed:

      <import plugin="org.apache.bcel" version="0.0.0" match="greaterOrEqual"/>

I found this newer version but I don't want to add if it's not needed and nothing appears to depend on this:

https://repo1.maven.org/maven2/org/apache/bcel/bcel/6.7.0/

[merks]

@nitind

I built a new recipe for the latest com.google.javascript

https://repo1.maven.org/maven2/com/google/javascript/closure-compiler/v20230802/

but there are quite a few compile errors

[jukzi]

@merks try bugtracker. The committer seem to be responding there

[merks]

@nitind

It would great if WTP the newer jdom consistently:

[nitind]

@nitind

It would great if WTP the newer jdom consistently:

I don't know how you find the time. I tried a couple of changes last week that did not succeed, but even if this latest one results in a successful--single org.jdom version and all--build, it's not something I'd want to merge this late into the endgame.

[merks]

I see. WTP overall is super complicated with so many separate moving parts...

[merks]

@nitind

FYI, one warning that just caught my attention is this one, where I just noticed that it's the same bundle named twice:

Both 'org.eclipse.jst.j2ee.core' and 'org.eclipse.jst.j2ee.core' register a package for 'application.xmi'

It's caused by the duplicate registrations here:

https://git.eclipse.org/c/jeetools/webtools.javaee.git/tree/plugins/org.eclipse.jst.j2ee.core/plugin.xml#n19