Using Okapi components as a Maven/Gradle dependency

[Graeme West]

Hi there,

This is perhaps more of an enquiry rather than an enhancement, but I can’t find any way to make the Okapi applications available through dependency resolution (specifically, using Gradle, but also Maven).

I want to add a dependency to my existing project that grabs the tools from Bintray, or uses a cached version if it’s available, so that I can then use the tools (e.g. rainbow.jar, tikal.jar) from command-line tasks to perform things like pseudotranslation, extraction, and so on.

I wrote a Gradle task to download the Okapi applications ZIP file, but the problem is that this ZIP is platform-specific (and I don’t want to hammer your download mirrors!). If therefore has to have complex logic to determine which one to load, depending on whether you’re on Linux or Windows. The ‘Okapi_Lib’ ZIP file isn’t platform-specific, but it doesn’t include Rainbow’s JAR.

Making Okapi available as a packaged dependency would mean that my local artefact repository (Artifactory/Nexus) can cache it. Then my Jenkins build slaves can install it quickly when they need it.

Any help or advice would be appreciated.

Thanks.

GW

[Graeme West]

Sorry, I just spotted the Maven Central binary releases! That solves my problem for Rainbow - I can get it as a JAR.

But what about Tikal? There doesn’t seem to be a JAR release for that.

[YvesS]

Tikal is released as part of the cross-platform Okapi_Lib package (https://bintray.com/okapi/Distribution/Okapi_Lib).
And you are right: there is no self-contained JAR for Tikal at this time. It comes as a batch or shell file calling a small JAR with external dependencies in the lib sub-folder of the package.

[Graeme West]

Thank you.

Is there a way to get the Rainbow JAR as a Gradle dependency, with all its dependencies?

I am getting errors like this when attempting to invoke Rainbow from a JavaExec task:

Successfully started process 'command 'C:\Program Files\Java\jdk1.8.0_211\bin\java.exe''
java.lang.NoClassDefFoundError: net/sf/okapi/common/filters/IFilterConfigurationMapper
        at net.sf.okapi.applications.rainbow.Main.main(Main.java:43)
Caused by: java.lang.ClassNotFoundException: net.sf.okapi.common.filters.IFilterConfigurationMapper
        at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 1 more

‌

Here is my Gradle dependencies block:

dependencies {
    RainbowConfig (group: 'net.sf.okapi.applications', name: 'okapi-application-rainbow', version: '0.37', ext: 'jar')
    RainbowConfig (group: 'net.sf.okapi.lib', name: 'okapi-lib-extra', version: '0.37', ext: 'jar')
    SWTConfig (group: 'org.eclipse.platform', name: 'org.eclipse.swt', version: '3.111.0')

}

‌

Before I added the ‘SWTConfig’ line, I was also getting this:

Successfully started process 'command 'C:\Program Files\Java\jdk1.8.0_211\bin\java.exe''
java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Display
        at net.sf.okapi.applications.rainbow.Main.main(Main.java:29)
Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.widgets.Display
        at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 1 more

Thanks,

GW

[Chase Tingley]

Here’s how Longhorn pulls in Rainbow and its dependencies -- since Longhorn runs in a server, it excludes all the SWT UI dependencies. Substitute the appropriate Okapi dependency version for `${project.version}.

  <dependency>
      <groupId>net.sf.okapi.applications</groupId>
      <artifactId>okapi-application-rainbow</artifactId>
      <version>${project.version}</version>
      <exclusions>
        <exclusion>
          <groupId>org.eclipse.platform</groupId>
          <artifactId>org.eclipse.swt.cocoa.macosx</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.eclipse.platform</groupId>
          <artifactId>org.eclipse.swt.cocoa.macosx.x86_64</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.eclipse.platform</groupId>
          <artifactId>org.eclipse.swt.gtk.linux.x86</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.eclipse.platform</groupId>
          <artifactId>org.eclipse.swt.gtk.linux.x86_64</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.eclipse.platform</groupId>
          <artifactId>org.eclipse.swt.win32.win32.x86</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.eclipse.platform</groupId>
          <artifactId>org.eclipse.swt.win32.win32.x86_64</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

[Mihai Nita]

Should we mark this resolved & closed?

[Chase Tingley]

Closing this.