Jigsaw/jpkg meeting synopsis

[Deepak Bhole]

Hi,

My name is Deepak Bhole and I work at Red Hat on the Java team. Last
week, we had a meeting with Mark and Dalibor from Sun, and few others here
at Red Hat. The purpose was to try and come up with a plan for 
Jigsaw/jpkg integration for various Linux distros. Here is a summary 
of what came out of it:

The meeting focused mostly on the jpkg tool, and how it and similar
tools/scripts can help distributions integrate the Jigsaw module system.

For posterity, I am going to include all approaches that were discussed,
and their pros and cons.

-------------------------------------------------------------------------------

== Iteration 1 ==

Goal
----
Make it easy to produce native packages that take advantage of the dependency
information in module-info file.

Approach
--------
The original idea was to have a tool -- jpkg -- that would accept built class
files, resources, and additional metadata and use it to create consumable
packages (rpm, deb, etc).

Pros
----
Easy for independent developers to provide natively consumable distribution
units.

Cons
----
The problem with this approach is integration with various major distribution
build systems. Fedora for example, uses a system called Koji. The workflow for
Koji is as follows:

    1.  Download upstream source code
    2a. Write up spec file that will call ant/maven/etc.
    2b. Set up locations for where the jars will end up on the target system
    2c. Write post install/uninstall scripts as needed
    3.  Upload the spec file and sources to cvs, and call Koji build
    4.  Koji then checks out from cvs, unpacks the sources, builds, writes the
        final rpms, sends them for signing, and makes them available in the
        repos

jpkg tries to solve #2. However, 2b varies based on distributions. That is the
first part of the problem -- different distributions have different
conventions, and coming up with a generic one that appeals to everyone would be
is quite difficult, if not impossible. The second part of the problem is that
jpkg produces rpms, which have no entry point into #4 (once step 3 is
done, everything is automated). With no entry point to #4, it can have no
influence over final packages.

== Iteration 2 ==

Goal
----
Unchanged.

Approach
--------
As seen in the cons for iteration 1, jpkg would be unusable in distributions
that have their own build infrastructure. So the next iteration was to
have jpkg create rpm spec file. The developer could then modify these as needed,
and send them off to build.

Pros
----
Allows flexibility across distributions, as packagers can adapt the spec file
to their distribution conventions.
Allows integration with the build system.

Cons
----
Once a spec file is written by the tool, it will begin to diverge. Essentially
creating a branched version. This could be mitigated by having jpkg take an
existing spec file and update it. However, what was a 1 stage process before,
is now 2 stages and more work.

== Iteration 3 ==

Goal
----
Unchanged.

Approach
--------
The approach that we ended up with, is one where packagers have to do minimal
work and the benefits of the module system are reaped behind the scenes.

The jpkg tool can have 2 phases. The first phase will compute the dependencies,
module database location, etc., and there will be an option to have it dump
this data into some agreed upon format, and exit. Otherwise, it will continue
on to the second phase and produce final rpms.

Distributions will integrate scripts that will be able to call jpkg phase 1,
and take its output and dynamically change the output RPM to inject
dependencies, add post scripts, etc.

Thus under this approach, the distribution packgers would have to simply update
their packages to remove manual dependencies, and rebuild -- the new rpm
scripts would take care of the rest.

Pros
----
Packagers will have to do little to provide Jigsaw integration.
Independent developers can use jpkg to build full rpms.

Since jpkg output will be used by rpm finalization scripts, it can provide
metadata that conforms to a globally unique java namespace, so that
independently developed packages can work with system installed ones.

Cons
----
Integration with rpm/deb will be challenging work. Especially ensuring that
independent + distribution packages play nice. Most of the onus will be
on Java however, as rpm/deb can only unpack to target locations and update
databases. It is upto Java to figure out how to use it all in an integrated
manner.

-------------------------------------------------------------------------------

For the first little while, we would need a hybrid system that remains
compatible with what distributions currently ship, and Jigsaw. This wouldn't be
too difficult thanks to symlinks. RPM can continue installing wherever they
usually install. The automated scripts can take care of linking to these from
a centralized location. The implementation details of it all still need to be
hammered out, but it should be doable.

Deepak