Skip to content

NOTICEs ‐ updating this file

Jump to bottom
Scott Kurz edited this page Nov 28, 2023 · 2 revisions

NOTES

  • We need to produce the NOTICES for everything we package and ship, but NOT content that is merely a dependency.
    • For the "uber JARs" we need to therefore include transitive dependencies.
    • OTOH, for things like the jakarta.jdt, microprofile.jdt bundle JARs, which do not ship their dependencies because they function as Eclipse plugins and import their dependencies from other bundles in the Eclipse install, we are covered by simply declaring a dependency on the LSP4Jakarta, LSP4MP projects, respectively, and do not need to worry about transitive dependencies.

There are currently 4 uber JARs we pull into Liberty Tools Eclipse: 1) LCLS (liberty-ls, for bootstrap.properties, server.env); 2) LCLS lemminx extension; 3) mp.ls; 4) jakarta.ls

FIRST STEPS

Since we have settled down a bit at this point, we should leverage the existing work we've done and think about this as more of a "delta"

  1. Do mvn dependency:tree from each individual repo and root dir that we consume, e.g. .../liberty-language-server/lemminx-liberty
  • NOT FROM THE TYCHO CONSUMING DIR - Though normally this is what you'd do, running dependency:tree doesn't seem to work correctly for the io.openliberty.tools.eclipse.lsp4e bundle..maybe because it's a bundle/plugin but pulls in the shaded uber JARs? IDK.
  1. Do the diff comparing the old, previously consumed release version vs. the current one to easily see the differences and as a double-check.
  2. only consider 'compile'-scoped dependencies, since this is all that would typically be packaged ('provided' and 'test' wouldn't be pkgd; 'system' would likely be a Tycho-ism to ignore; not sure if we have any 'runtime'-scoped deps.. that might require diving into).
  3. It is helpful to check a "sampling" of these entries by doing a jar tf listing of the actual JARs we pull in, to locations: bundles/io.openliberty.tools.eclipse.lsp4e/server/*/*.jar, e.g. bundles/io.openliberty.tools.eclipse.lsp4e/server/jakarta-langserver/org.eclipse.lsp4jakarta.ls.jar. It is a decently complex build, using the shade plugin, etc.... so it'd be conceivable something shows up in the dependency tree but later gets filtered out. It might not be worth the trouble... and probably easy enough to err on the side of listing the dependency, but consider this as another view of the dependencies.

HOW TO UPDATE BASED ON LICENSE

For some of the licenses we track them with an entry including the version we use. For some we just track the group/artifact id . Some we also track the copyright statement.

Track versions

  • EPL - update source link, per version
  • CDDL - same as EPL, (but just javax.activation so likely no new entries)
  • Unicode - same as EPL (but just unicode so likely no new entries)

Don't track versions

  • BSD - 1x/year - update copyright year
  • LGPL - 1x/year - update copyright year but just org.jboss.logging:jboss-logging-processor | Copyright (C) 1991, 1999 Free Software Foundation, Inc Not sure it's even being used but not worth removing
  • MIT - 1x/year - update copyright year

Just group:artifact

  • ASL - just group/artifactID

FOLLOW-UPS

  1. We probably don't need to track the source version coordinates precisely in the URL. The OL runtime does not: https://github.com/OpenLiberty/open-liberty/blob/integration/dev/build.image/publish/NOTICES
  2. follow-up with OL runtime to see what automation there is in building this
  3. We could've just started w/ LCLS and LSP4Jakarta and done a copy/paste into ours. Seems like LCLS has extra entries that aren't being shipped, while LSP4Jakarta is incomplete and missing entries, so just did this ourselves.
  4. If we ever start bundling plugins in our Eclipse installs (eg update site content), it'd seem we'd need to include that in our processes
Clone this wiki locally