Several third-party libraries are not updated to the latest version in several instances, some of them with known issues.

Submitted by Guido Wachsmuth on 28 June 2016 at 18:25

On 28 June 2016 at 18:25 Guido Wachsmuth commented:

Oskar will provide a list of required updates.


On 28 June 2016 at 18:32 Guido Wachsmuth commented:

Here is some feedback from one of the teams using Spoofax:

General guideline is to not use a lib if you can avoid it with reasonable effort. We had some cases where a lib was used only in a few places and new features in Java made it unnecessary to rely on it. This may not be a situation that you are facing - I wanted to mention it as an option.

Our guideline is to attempt to use the latest version of 3rd party libraries. It should be fairly easy to determine that at the components’ home pages. We are also asked to lookup if any security issues are reported on the libraries, e.g. at https://www.us-cert.gov/. For example, the commons-collections-3.2.1 lib is highlighted there: https://www.us-cert.gov/ncas/current-activity/2015/11/13/Apache-Commons-Collections-Java-Library-Vulnerability

In some cases the libs bundled with Spoofax’s 3rd party lib may not be up to date. In these cases you may substitute the used libs to the latest on a branch, e.g. upgrade to commons-collections-3.2.2 from commons-collections-3.2.1. We have a mechanism in gradle to do that - not sure if this is supported in the Spoofax POM files or equivalent?

Ideally, we like to see commons-collections-4.1.1 but this is not absolutely necessary but highly desirable.


On 28 June 2016 at 19:38 Oskar van Rest commented:

I have compiled a list with recommended upgrades:
https://docs.google.com/spreadsheets/d/1mURr9uVloMkAKAemDHv87bk4p7JQvg43NTNSSO4zaCE/edit?usp=sharing

please let me know in case an upgrade required a change to Java code (i.e. because the interface of a library changed) such that I can double check if nothing breaks for our projects.


On 4 July 2016 at 15:54 Gabriël Konat commented:

Your changes in pull requests make the build fail:

[ERROR] /Users/gohla/spoofax/master/repo/spoofax-releng/runtime-libraries/org/metaborg/runtime/task/src/main/java/org/metaborg/runtime/task/primitives/ITaskEngineContext.java:[3] The import javax.annotation.Nullable cannot be resolved
[ERROR] /Users/gohla/spoofax/master/repo/spoofax-releng/runtime-libraries/org/metaborg/runtime/task/src/main/java/org/metaborg/runtime/task/primitives/ITaskEngineContext.java:[8] Nullable cannot be resolved to a type

On 4 July 2016 at 19:37 Gabriël Konat commented:

I have merged your PRs, bumped most things to the latest version, and fixed some compatibility issues. I could not bump Guice to 4.1.0 because it is incompatible with Maven, which uses Guice 4.0, so I bumped it to 4.0. I could not bump Guava from 17 to 19 because the IntelliJ plugin requires Guava 19. Maybe we can update it without issues but I have to ask Daniel. Apart from that, is it ok now?


On 4 July 2016 at 20:31 D. Pelsmaeker commented:

Yes, IntelliJ uses Guava 17 and updating ours to 19 would cause a version conflict with the plugin’s.


On 4 July 2016 at 21:40 Gabriël Konat commented:

The resulting uber JAR (I will change the artifact id later) has the following dependencies: http://artifacts.metaborg.org/content/repositories/snapshots/org/metaborg/build.uber/2.0.0-SNAPSHOT/build.uber-2.0.0-20160704.181340-5.pom


On 5 July 2016 at 18:57 Oskar van Rest commented:

This is great. I have also checked with the other team and they are happy with these upgrades. Thanks a lot.


On 6 July 2016 at 20:15 Oskar van Rest closed this issue.

Log in to post comments