Upstream project rejected my proposal to make it proper OSGi (codelibs/nekohtml#5) and we use an ancient version in Linux Tools which has multiple CVEs (https://mvnrepository.com/artifact/net.sourceforge.nekohtml/nekohtml/1.9.22).
If this is not the right place please move to the proper place and guide me how to do it.

SimRel 2024-09 M1 and M2 versions of the Java IDE (EDIT: the JEE package, sorry) give an ExceptionInitializerError when using EGit. The reason is, that there are multiple implementations of org.apache.commons.logging available. The older one (1.2) comes from Orbit (https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-osgi/tp/other/MavenSupplement.target) and newer ones (1.3.2 and 1.3.3) from egit, jgit, platform and "supplement" itself via Maven (https://github.com/eclipse-orbit/orbit-simrel/blob/main/report/maven-osgi/supplement/REPORT.md). I'm not sure where that bug report belongs to, please advise if wrong here.

To reproduce: File/Import/Git/Projects from Git/Clone URI, use https://github.com/eclipse-orbit/orbit-simrel.git, Next:

java.lang.ExceptionInInitializerError at org.apache.http.conn.ssl.SSLConnectionSocketFactory.<clinit>(SSLConnectionSocketFactory.java:151) at org.eclipse.jgit.transport.http.apache.HttpClientConnectionFactory$HttpClientSession.configure(HttpClientConnectionFactory.java:81) at org.eclipse.jgit.transport.http.apache.HttpClientConnectionFactory$HttpClientSession.configure(HttpClientConnectionFactory.java:1) at org.eclipse.jgit.transport.TransportHttp.httpOpen(TransportHttp.java:1062) at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:651) at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:465) at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:170) at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:131) at org.eclipse.egit.core.op.ListRemoteOperation.run(ListRemoteOperation.java:116) at org.eclipse.egit.ui.internal.clone.SourceBranchPage$9.run(SourceBranchPage.java:377) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:124) Caused by: org.apache.commons.logging.LogConfigurationException: The chosen LogFactory implementation does not extend LogFactory. Please check your configuration. (Caused by java.lang.ClassCastException: The application has specified that a custom LogFactory implementation should be used but Class 'org.apache.commons.logging.impl.LogFactoryImpl' cannot be converted to 'org.apache.commons.logging.LogFactory'. The conflict is caused by the presence of multiple LogFactory classes in incompatible classloaders. Background can be found in http://commons.apache.org/logging/tech.html. If you have not explicitly specified a custom LogFactory then it is likely that the container has set one without your knowledge. In this case, consider using the commons-logging-adapters.jar file or specifying the standard LogFactory from the command line. Help can be found @http://commons.apache.org/logging/troubleshooting.html.) at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1154) at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:960) at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:957) at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:624) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655) at org.apache.http.conn.ssl.AbstractVerifier.<init>(AbstractVerifier.java:61) at org.apache.http.conn.ssl.AllowAllHostnameVerifier.<init>(AllowAllHostnameVerifier.java:44) at org.apache.http.conn.ssl.AllowAllHostnameVerifier.<clinit>(AllowAllHostnameVerifier.java:46) ... 11 more Caused by: java.lang.ClassCastException: The application has specified that a custom LogFactory implementation should be used but Class 'org.apache.commons.logging.impl.LogFactoryImpl' cannot be converted to 'org.apache.commons.logging.LogFactory'. The conflict is caused by the presence of multiple LogFactory classes in incompatible classloaders. Background can be found in http://commons.apache.org/logging/tech.html. If you have not explicitly specified a custom LogFactory then it is likely that the container has set one without your knowledge. In this case, consider using the commons-logging-adapters.jar file or specifying the standard LogFactory from the command line. Help can be found @http://commons.apache.org/logging/troubleshooting.html. at org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1108) ... 19 more

It's not obvious (to me) which commit in this repo corresponds to what was released as https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2023-12/index.html

I can try to infer based on dates, but having actual tags would be much easier.

My actual use case is to be able to see "what has changed in Orbit since the last release that might concern me?". I can look at https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2023-12/index.html and https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2024-03/index.html but the "diff" is not obvious.

I'd like to be able to do something like git log v2023-12.. (or diff) on my local clone and see what changed (with commit messages for context).

Hi, where is <unit id="org.aopalliance" version="1.0.0.v20220404-1927"/>
gone?

i can see

<?xml version="1.0" encoding="UTF-8"?>
<p2:Requirement
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:p2="http://www.eclipse.org/oomph/p2/1.0"
    name="org.eclipse.orbit.maven.aopalliance.feature.group"
    versionRange="[4.29.0.v20230720-0728,4.29.0.v20230720-0728]"/>

only
version number seems wired as guice uses 1.0

For the WindowBuilder project, I'd like to get rid of org.eclipse.wb.swing.FormLayout.lib, which contains both jgoodies-common and jgoodies-forms as embedded jars.

Newer versions have become proprietary, so it's unlikely that any fix can be added to the upstream project. Ideally, I'd like to use the latest release, before the project became closed source:

https://mvnrepository.com/artifact/com.jgoodies/jgoodies-common/1.8.1
https://mvnrepository.com/artifact/com.jgoodies/jgoodies-forms/1.9.0

BIRT has their own copy of org.apache.axis. There are discussions about vulnerabilities in this issue:

eclipse-birt/birt#662

I believe those also affect the version currently provided by orbit.

See also

eclipse-birt/birt#1424

@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/

Consider https://repo1.maven.org/maven2/org/apache/derby/derby/10.16.1.1/

<groupId>org.apache.derby</groupId>
<artifactId>derby</artifactId>
<version>10.16.1.1</version>

Firstly, it doesn't provide associated source:

Secondly, the OSGi metadata is broken specifying jars that do not exist:

To produce high quality artifacts, we need to repackage the content available from here:

https://dlcdn.apache.org/db/derby/db-derby-10.16.1.1/

This is similar to what we need to do for Ant.

I have made a minimal(ish) test case from CDT's target platform here: https://github.com/jonahgraham/orbit-junit-issue

The head commit which uses the orbit-aggregation/nightly fails with this error:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:3.0.5:validate-classpath (default-validate-classpath) on project org.eclipse.cdt.util: Execution default-validate-classpath of goal org.eclipse.tycho:tycho-compiler-plugin:3.0.5:validate-classpath failed: org.osgi.framework.BundleException: Bundle org.eclipse.cdt.util cannot be resolved:org.eclipse.cdt.util [100]
[ERROR] Unresolved requirement: Require-Bundle: org.junit
[ERROR] -> Bundle-SymbolicName: org.junit; bundle-version="4.13.2.v20230725-0701"
[ERROR] org.junit [21]
[ERROR] Unresolved requirement: Import-Package: org.hamcrest; version="1.3.0"

The parent commit builds fine with the only difference I can see being the version of hamcrest 1.3 I am using.

These sites with jar-signed content should do baseline replacement:

• https://download.eclipse.org/tools/orbit/simrel/maven-bnd/
• https://download.eclipse.org/tools/orbit/simrel/maven-sign/
• https://download.eclipse.org/tools/orbit/simrel/orbit-legacy

This site does not need that because does not modify the direct-from-maven artifacts:

• https://download.eclipse.org/tools/orbit/simrel/maven-osgi/

The aggregation consumes from the sites above so does not need special handling because it aggregates already-baseline-replaced content:

• https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/

The bundles org.apache.axis.ant and org.apache.axis both export package org.apache.axis but org.apache.axis.ant does not import that package and of course it's a split package. This leads to wiring problems like this in the JEE 2023-09 M3 package:

org.osgi.framework.BundleException: Could not resolve module: org.eclipse.jst.ws.axis.consumption.core [556]
  Unresolved requirement: Require-Bundle: org.apache.axis.ant; bundle-version="[1.4.0,2.0.0)"
    -> Bundle-SymbolicName: org.apache.axis.ant; bundle-version="1.4.0.v20230802-0838"
       org.apache.axis.ant [66]
         No resolution report for the bundle.  Bundle was not resolved because of a uses constraint violation.
  org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.apache.axis.ant [osgi.identity; osgi.identity="org.apache.axis.ant"; type="osgi.bundle"; version:Version="1.4.0.v20230802-0838"] because it exports package 'org.apache.axis' and is also exposed to it from resource org.apache.axis [osgi.identity; osgi.identity="org.apache.axis"; type="osgi.bundle"; version:Version="1.4.0.v20230730-0709"] via the following dependency chain:

  org.apache.axis.ant [osgi.identity; osgi.identity="org.apache.axis.ant"; type="osgi.bundle"; version:Version="1.4.0.v20230802-0838"]
    import: (osgi.wiring.package=org.apache.axis.client)
     |
    export: osgi.wiring.package: org.apache.axis.client; uses:=org.apache.axis
    export: osgi.wiring.package=org.apache.axis
  org.apache.axis [osgi.identity; osgi.identity="org.apache.axis"; type="osgi.bundle"; version:Version="1.4.0.v20230730-0709"]
	at org.eclipse.osgi.container.Module.start(Module.java:463)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1852)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1845)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1786)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1750)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1672)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)

That "package" contains only an antlib.xml:

Hi @merks. what is the current policy on breaking changes after M3 (in this case guava)

Hi, do i see it correct that

https://download.eclipse.org/oomph/simrel-orbit/2023-09

is outdated and replaced by

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2023-09

The prior Orbit Aggregation release and latest milestone, at the moment, have the ancient com.google.javascript_0.0.20160315.v20161124-1903 (as Closure Compiler). Around 2 days ago, nightly changed over to the very incompatible com.google.javascript 0.0.20230802.v20230927-1600 (JSDT can not compile against it, and does not find the old version explicitly listed in its feature.xml). Which one should be expected in M1?

The Platform's RC2/final build is Wednesday so I think it would be best to produce a release repository for the current state of Orbit for contribution to the Platform's target platform:

eclipse-platform/eclipse.platform.releng.aggregator#1392

My generator indicates that there are already a few updates available from Maven Central, but I don't think it's a good idea to incorporate those right before the Platform produces RC2/final and right before the rest of us are producing or have already produced RC1.

@jonahgraham

I just wanted to check that you agree before I spin the final builds to produce release URLs tomorrow...

I think that this request makes sense. Feel free to correct me if I'm horribly, horribly wrong.

As part of the process of bundlifying modules, does it make sense to include an Eclipse-SourceReference entry in the header that just points to the source JAR? I've observed that this isn't included in at least the handful of bundles that I checked.

I'm thinking of how this might be used in a scenario where the source bundles have not be added to the configuration.

I assume that, the existence of an scm scheme suggests that other schemes are possible. My search-fu has, unfortunately, failed me thus far. Whether or not the IDE can currently make sense of the scheme is a separate problem.

The new version of JFFI contributed here and used by linuxtools (which is included in CPP and Embed CPP package) here causes notarization to fail because the jnilibs are not signed.

In EBR based Orbit we do sign the jnilibs as part of the Orbit process. See this bugzilla for reference the last time JFFI failed and this part of pom.xml for how we sign the jnilibs.

Note that JNA needed signing in the past, but Apple's notarization processes sometimes look arbitrarily deep in jars and provides a moving target that we need to chase regularly. Also, the JNA maintainers are not interested in providing signed jnilibs in their release.

{
  "logFormatVersion": 1,
  "jobId": "b0fe30eb-7a90-48a0-9b26-de50880fcd81",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "eclipse-cpp-2023-09-M2-macosx-cocoa-aarch64-6370600730443560226.dmg",
  "uploadDate": "2023-08-03T18:24:52Z",
  "sha256": "320d3da6e1e89a841ba4e796f083ddec1c66e81bb11a1c6c9ab444443b2bdf84",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "eclipse-cpp-2023-09-M2-macosx-cocoa-aarch64-6370600730443560226.dmg/Eclipse.app/Contents/Eclipse/plugins/com.github.jnr.jffi.native_1.3.11.jar/jni/Darwin/libjffi-1.2.jnilib",
      "message": "The binary is not signed with a valid Developer ID certificate.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721",
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "eclipse-cpp-2023-09-M2-macosx-cocoa-aarch64-6370600730443560226.dmg/Eclipse.app/Contents/Eclipse/plugins/com.github.jnr.jffi.native_1.3.11.jar/jni/Darwin/libjffi-1.2.jnilib",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733",
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "eclipse-cpp-2023-09-M2-macosx-cocoa-aarch64-6370600730443560226.dmg/Eclipse.app/Contents/Eclipse/plugins/com.github.jnr.jffi.native_1.3.11.jar/jni/Darwin/libjffi-1.2.jnilib",
      "message": "The binary is not signed with a valid Developer ID certificate.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721",
      "architecture": "arm64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "eclipse-cpp-2023-09-M2-macosx-cocoa-aarch64-6370600730443560226.dmg/Eclipse.app/Contents/Eclipse/plugins/com.github.jnr.jffi.native_1.3.11.jar/jni/Darwin/libjffi-1.2.jnilib",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733",
      "architecture": "arm64"
    }
  ]
}

It appears that org.apache.ant is the only EBR-based bundle that cannot be migrated. Why is that?

Firstly the bundle has content that does not come from any Maven artifact.

https://repo1.maven.org/maven2/org/apache/ant/

I.e., the bin and etc folder from this download

https://dlcdn.apache.org//ant/binaries/apache-ant-1.10.14-bin.zip

The bin and etc folders are copied from here

as described here:

It also has special EBR "instructions":

That's because the Platform expects such an all-in-one bundle, separate libraries exactly as it is structure now (and like in the binary download).

@jonahgraham

Should I try to create infrastructure to generate/automate all this---that is, stuff that doesn't use EBR---or shall we maintain EBR "forever" with this bundle as effectively the one and only usage?

With both Tycho 2.7.5, 3.0.5, and probably 4.0.3, a build against the Platform's 4.30 version fails because of ant dependency checking.

Update: No it does not fail for Tycho 4.0.3. So using the latest Tycho is definitely the best step forward.

Firstly one sees this in the log:

[WARNING] The POM for org.eclipse.orbit:ant:jar:1.10.14 is missing, no dependency information available

But then the build fails completely like this:

[ERROR] Failed to execute goal on project org.eclipse.emf.test.core: Could not resolve dependencies for project org.eclipse.emf:org.eclipse.emf.test.core:eclipse-test-plugin:2.29.0-SNAPSHOT: Failure to find org.eclipse.orbit:ant:jar:1.10.14 in https://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central-id has elapsed or updates are forced -> [Help 1]

The problems are highlighted here:

• eclipse-packaging/packages#66
• eclipse-tycho/tycho#2881

It appears that the following functions well as a workaround:

  <repositories>
    <repository>
      <!--
        Tycho is insisting on accessing the "upstream" artifact for this Ant, see https://github.com/eclipse-packaging/packages/issues/66
        To make this work we need to match the repo used in Orbit's build for the repository:
        https://github.com/eclipse-orbit/orbit-simrel/blob/f6ea491f4ada5d6d6750d8118bf40d9802993376/maven-bnd/tp/MavenBND.target#L1203
      -->
      <id>orbit-approved-artifacts</id>
      <url>https://repo.eclipse.org/content/repositories/orbit-approved-artifacts</url>
    </repository>
  </repositories>

So the open question for Orbit is, should I change the coordinates used to publish the transformed ant downloads from this location

• https://repo.eclipse.org/content/repositories/orbit-approved-artifacts/org/eclipse/orbit/ant/1.10.14

to use coordinates that will exactly match this:

• https://repo1.maven.org/maven2/org/apache/ant/ant/1.10.14/

keeping in mind that these are NOT THE SAME ARTIFACTS so there seems some risk in conflating the two.

In other words, should I replace the org.eclipse.obit prefix/groupId with org.apache for the following build process:

https://github.com/eclipse-orbit/orbit-simrel/tree/main/maven-ant

Everyone having broken Tycho builds is also extremely unpleasant so I'm not sure how best to balance risk against unpleasantness...

It would be helpful to get report what's pending update in mylyn-docs.

The latest version of Xalan available at Maven Central does not provide source

https://repo1.maven.org/maven2/xalan/xalan/2.7.3/

We are current providing a much older version:

https://repo1.maven.org/maven2/xalan/xalan/2.7.2/

On the webpage for M3 two versions of guava seem to appear in the following locations

• Orbit Maven OSGi All 4.29

• Guava: Google Core Libraries for Java 32.1.2 2,970.3KB

The repo only contains the 32.1.2 version (as expected) but I don't understand where the first entry on the webpage comes from, the feature.xml seems to refer to 32.1.2 IIUC.

This may be a resolved problem as latest nightly doesn't have the problem

Please see the queries in https://bugs.eclipse.org/bugs/show_bug.cgi?id=579583 which should have migrated.

While checking https://ci.eclipse.org/simrel/job/simrel.build/job/main/34/consoleFull to see whether the updated no-LPG-redistribution OCL contribution looks ok, I notice

00:03:14 - mirroring artifact osgi.bundle,org.eclipse.datatools.sqltools.data.ui,1.5.0.202305310959
00:03:14 - mirroring artifact osgi.bundle,net.sourceforge.lpg.lpgjavaruntime,1.1.0.v201004271650

as well as

00:03:27 - mirroring artifact osgi.bundle,org.eclipse.ocl.examples.xtext.idioms.ui.source,1.19.0.v20231016-0649
00:03:27 - mirroring artifact osgi.bundle,lpg.runtime.java.source,2.0.17.v201004271640

This matches what the old Orbit offered. But AFAIAA only lpg.runtime.java is required to provide the lpg.runtime package.

I suspect this stems from a longstanding confusion. The two bundles have similar class names but lpg.runtime.java is typically 10% bigger and version 2.x rather than 1.x. Although net.sourceforge.lpg.lpgjavaruntime is a superficially better name properly reflecting its domain authorities and was built 10 minutes later, it is version 1 rather than version 2.

I suggest that net.sourceforge.lpg.lpgjavaruntime need not be provided by the new stripped down Orbit. (I'm not sure whether the log line sequencing indicates that the datatools distribution needs updating.)

(My 4.30M1 installation uses just lpg.runtime.java for OCL and friends.)

It's available here:

https://repo1.maven.org/maven2/net/i2p/crypto/eddsa/0.3.0/

But if we try to use it directly, its package requirements fail:

[ERROR]   Missing requirement: net.i2p.crypto.eddsa 0.3.0 requires 'java.package; sun.security.x509 0.0.0' but it could not be found
[ERROR]   Cannot satisfy dependency: org.eclipse.orbit.maven.osgi.all.feature.group 4.30.0.v20230928-1507 depends on: org.eclipse.equinox.p2.iu; net.i2p.crypto.eddsa [0.3.0,0.3.0]

It has this import:

Import-Package                          sun.security.x509

The EBR recipe rewraps it with that import optional:

Import-Package                          sun.security.x509;resolution:=optional

I've prototyped the following.

Using a design pattern similar to the one for maven-osgi and reusing the same generator/analyzer infrastructure, we can start with this very simple target platform:

The generator expands the BOMs to produce a target with the full set of Jetty 12 bundles:

That target also includes the full set of dependencies of all these Jetty 12 bundles:

That part was hand crafted such that a Tycho build with <includeAllDependencies>true</includeAllDependencies> is successful.

There is a lot of content:

Everything is updated automatically based on what's available at Maven central.

A content report is produced:

And of course an update site of just the Jetty 12 bundles is produced as usual:

I think this approach will make it easier for SimRel consumers to align on Jetty versions as Jetty is updated. I think even just the MavenJetty.target is a useful resource for people wishing to represent the required dependencies on Jetty and Jetty's transitive dependencies in their own *.target...

@jonahgraham

Any concerns about hosting this in the repo along with the other components?

If not, I will proceed with this tomorrow morning.

caffeine is a "drop in" alternative for guavas CacheBuilder and friends, in fact guava recommends it over it's own cache code.

com.github.ben-manes.caffeine:caffeine:3.1.8

Thanks
George