Cannot build JMC

[Jie Kang]

On Mon, Jun 3, 2019 at 1:26 PM Simone Bordet <simone.bordet at gmail.com> wrote:
>
> Hi,
>
> On Mon, Jun 3, 2019 at 6:53 PM Jie Kang <jkang at redhat.com> wrote:
> > I recall contribution of JMC-6370 [1] to allow building with OpenJDK 8
> > without OpenJFX. My search shows that this was not backported to
> > jmc/jmc7. I'm sorry to have missed this; in Fedora/RHEL, we currently
> > remove all usages of OpenJFX, even the JOverflow plugin itself, when
> > building.
>
> Pardon my intrusion here, but so RedHat's JMC is not really the JMC
> from the official repository tag (e.g. 7.0.0-ga) but it's a different
> JMC with things removed and possibly things added?
> How do I know the differences between the two?

Hi,

Right, so considering 'upstream' as the OpenJDK JMC community project,
and downstreams as e.g. Red Hat, Oracle, or Azul. Red Hat does not
have binary distributions of JMC. I do hope to work in the upstream
community to have 'upstream' binary builds available, similar to
AdoptOpenJDK builds of the JDK.

For Red Hat, the currently available downstream release of JMC is in
RHEL (Red hat Enterprise Linux) through the SCL (Software Collections)
program under the package name 'rh-jmc-jmc'. This was made available
March 13, 2019 in rhscl-3.2.z and is an early release of the upstream
jmc/jmc7 repository, as at the time, there was no 7.0.0-ga tag. As you
point out, there is little 'official' documentation on differences
from the jmc7 upstream build. I guess this was missed on my part,
sorry.

Sources for RHEL packages are always made available somewhere. Here is
a link to the spec and patches for rh-jmc-jmc [0].

[0] https://git.centos.org/rpms/rh-jmc-jmc/blob/c7/f/SOURCES

I can say that it is as close to the upstream content as possible and
that will always be my intent. It may include backports from upstream
jmc -> jmc7 that upstream does not do in order to fix things for
users, but I would be very surprised to see feature additions that are
not upstream first. I do commit as best I can to the upstream first
philosophy! The only difference of note at this time, in my opinion,
is that it excludes all of the optional plugins (such as JOverflow as
we do not support OpenJFX in RHEL). There are plans to include the
other optional plugins on a case-by-case basis in future releases,
and/or to provide users the ability to point to update sites at their
own risk, similar to the Eclipse distributions in Fedora and RHEL.

The RHEL release very closely mimics that of the Fedora release, so if
you're interested in what updates to RHEL might look like, you can see
the Fedora jmc package repository here [1], where you can see exactly
what patches are carried (check branch 'jmc', and in a week or two,
'jmc7'). The spec file has comments with justifications for each patch
(I sincerely hope). Some of these are obsolete as changes have been
made to upstream that resolve the issue, such as the update to use
javamail 1.6.x. Other changes will always be around as the build
system requirements differ from upstream (offline only, dependencies
from other rpms on the system, package *only* as an Eclipse RCP
application so a number of modules need not be built, and so on and so
forth).

[1] https://src.fedoraproject.org/rpms/jmc

For what it's worth, I am in the process of updating the Fedora JMC module with
* updated 'latest' stream tracking the latest commit in jmc/jmc; I am
probably going to update this once every 3 months, or maybe 6, kind of
as time permits.
* updated 'jmc7' stream tracking the jmc-7.0.0-ga tag in jmc/jm7: This
will only update if jmc/jmc7 sees updates

Afterwards, the patches applied will look very different. I hope this helps!

P.s. It's entirely possible other downstream distributions differ from
the upstream sources. Hopefully they will have documentation or even
better, source code, available too!


Regards,




>
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz