Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] Fixing existing release distributions due to GH-1098

That sucks. Nice of you to fix it though, even so far back as the 2.5 release :)

Håvard

On 24 Apr 2020, at 06:50, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:


As you may have seen, we have a problem with our release distribution, which includes a dependency on an org.json library that is not  approved for reuse by EF (see https://github.com/eclipse/rdf4j/issues/1098). The reason, by the way, is that its license is not approved: it includes an extra "use only for good not evil" clause which is not considered open-source compatible. 

I am not sure why we never detected this before to be honest, as this dependency has been lurking there since we first moved to Eclipse.

Fortunately, we really don't need this library, as we have Jackson, which is a superior choice for creating JSON artifacts anyway. The org.json library is only used in the RDF4J Workbench, in two places. I've put up a pull request which removes the old dependency and replaces its use with equivalent Jackson code. See https://github.com/eclipse/rdf4j/pull/2127 .

However, because we have no approval to use/distribute this library, we will need to retroactively fix the distributions of previous releases (only SDK and onejar downloads fortunately, not the artifacts on maven central).

How I plan to fix this is as follows:

1. I will create a new 3.1.4 patch release that includes this fix (and one or two other bug fixes). I will completely remove older 3.1.x releases from the download servers.
2. I will also create a new 3.2.0 Milestone build (milestone 2) that includes this fix. I will remove milestone 1 from the download servers.
3. For 3.0, I will generate a new release 3.0.5 with this change as the only fix. This will not be advertised but will become the linked download under the "older releases" heading on the website. Older 3.0.x releases will be removed from the download servers.
4. For 2.5, I will not generate a new release (as the rdf4j-storage and rdf4j-tools repos are now read-only, so I can't push tags), but what I will do is locally fix on the 2.5.5 tag, generate a new release SDK and zip, and just replace the existing downloads on the server. Older 2.5.x release will be removed.

For older releases than that I will just remove the download, and not bother with respinning it.

I'm not particularly happy about having to remove release artifacts, but in practice I think this will cause very little inconvenience - there are few good reasons why someone who downloads the SDK or onejar would need an ancient version. And if someone complains and does have a valid reason for needing it, we can always look at it on a case by case basis. 

Cheers,

Jeen
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev

Back to the top