Reorganizing the binaries

7 views
Skip to first unread message

Mihai Nita

unread,
Apr 12, 2022, 7:59:37 PM4/12/22
to Group: okapi-devel

Here is a laundry list of areas where I want to work next.
If there is something that does not sound right, please say so.
If all is good, at least you know what's going on :-)
 
You can see the changes for items 1-3 in the mihai_new_app_binaries branch

1. Convert the two "full libraries" artifacts from shaded jars to dependency-only jars

This means not code whatsoever, only a list of dependencies.
That way one can add them as dependency to their projects, and they will "drag in"
the 134 other okapi artifacts.
Because adding 100+ dependencies "by hand" is a bit of a pain :-)

  net.sf.okapi:okapi-lib    => okapi\deployment\okapi-framework-sdk
  net.sf.okapi:okapi-lib-ui => E:\git\okapi\okapi\okapi-ui\swt\deployment\okapi-lib-ui

2. Reorganize the downloadable binaries (zip files)

a. Eliminate the "developer binary" completely (okapi-lib_all-platforms_<ver>.zip)

This the the zip that contains the "big-lib" without gui, but with sources attached.
(okapi-lib-<ver>.jar & okapi-lib-<ver>-sources.jar)
And also contains "localweb", "javadoc", and "examples" folders.

We can probably assume that developers have access to maven, where they can
access all artifacts, including sources and javadoc.

And if they want to work offline, there is an easy, standard (maven) way to do it.

b. Create the applications binaries only (for end users)

These are the okapi-apps_<platform>-<architecture>_<version>.zip (and .dmg) files.

3. How to build the app binaries

Right now the ant script explicitly copies .jar files from the .m2 folder.
This is done for both okapi artifacts and dependencies.

But the list of dependencies is maintained "by hand" in the ant script.
Which means that in fact we miss some.

I plan to gather the .jar files in the lib folder using the maven dependencies mechanisms.
This means we get more dependencies in the lib folder.
And we trust what the creators of said third-party dependencies declared in their pom files.
If we call dependency X depends on artifact Y, but we never call an API that requires
the artifact Y, there is no way to know.
But some of them might be valid dependencies that we incorrectly exclude right now.
For example we don't include google auth and html, which are definitely needed for the Google connectors (google & googleautoml).

It also means one can build the binary packages without building Okapi at all,
just by using the artifacts from maven.

And that would be nice to have the okapi jar files in the app binaries being byte-identical
with the official maven artifacts.

4. Should we drop the support for 32 bit applications?

This only affects the binaries, because SWT has native shared libraries (.dll / .so / .jnilib)
But SWT dropped support for 32 bits a while ago.
So our 64 bit apps use SWT 3.119.0, while the 32 bit apps use SWT 3.108.0

We can keep it around until we get complaints that it breaks.
But it might be that nobody uses them anymore, so nobody will complain,
and we will be stuck with them for a long-long time.

5. Create some maven archetypes?

With the most useful "hello world" app(s) to start with?
Would include proper Java version, Okapi dependency, a simple pipeline with some basic steps.

6. Other topics

A. CI changes

We discussed that in depth a while ago, but I've only implemented part of it.


I want to finish that.
I hope to not break anything, but we might have failing builds for a while (when I work on it)
But I'll try to make it as short as possible

B. Jaxb & Longhorn build failures

That's the reason Longhorn currently fails
JAXB was removed from the jre in Java 9.
Okapi was fine, because we had it building and running on Java 11 for a long time.

There are several replacements that one can add as dependencies.
But because there is more than one, now we have to choose.

But Longhort was Java 9 only.
So now it is left without jaxb.

One might say: just use the same thing we use in Okapi proper.
But it does not seem that simple.
There are dependencies in Longhorn that "solved" this problem by dragging in their own jaxb implementations.
So we have a mix (conflicting).
I will get to it when I'm done with Okapi proper.

But also a warning to others: if you use Okapi in some server deployment that requires jaxb, expect some pain.

Thanks a lot,
Mihai

Mihai Nita

unread,
Apr 12, 2022, 8:03:09 PM4/12/22
to Group: okapi-devel

Alessandro Falappa

unread,
Apr 13, 2022, 4:09:52 AM4/13/22
to okapi...@googlegroups.com
+1 for items 1 to 4.
Item 5 would be nice to have but not essential in my opinion provided there's good documentation and a starter tutorial.
No opinion on item 6.

Regards,


Alessandro Falappa

Integrations Team Leader

Via Indonesia 23, 00144 Rome - Italy



--
You received this message because you are subscribed to the Google Groups "okapi-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/CAK69zbnTyXRSTcU%2Bg2MQicZsst%3DX-T1rJyXC2EPshE_PtyC0%3Dw%40mail.gmail.com.

jimbo

unread,
Apr 14, 2022, 10:40:17 AM4/14/22
to okapi...@googlegroups.com, Mihai Nita

This may be a good time to drop the 32-bit support. I agree #5 is optional.

Jim

--
You received this message because you are subscribed to the Google Groups "okapi-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-devel...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages