Bug 1801580 - Review Request: openjfx-11 - Rich client application platform for Java
Summary: Review Request: openjfx-11 - Rich client application platform for Java
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-11 09:23 UTC by Nicolas De Amicis
Modified: 2020-08-04 07:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-04 07:34:54 UTC
Type: ---


Attachments (Terms of Use)

Description Nicolas De Amicis 2020-02-11 09:23:43 UTC
Spec URL: https://deamn.fedorapeople.org/openjfx-11.spec
SRPM URL: https://deamn.fedorapeople.org/openjfx-11-11.0.3-0.fc31.src.rpm
Description: JavaFX/OpenJFX is a set of graphics and media APIs that enables Java
developers to design, create, test, debug, and deploy rich client
applications that operate consistently across diverse platforms.

The media and web module have been removed due to missing dependencies.

Fedora Account System Username: deamn

Comment 1 jiri vanek 2020-02-19 09:48:19 UTC
Hi!

On first glance, the spec looks good. Where the poms come from?
I tried to run fedora-review but the build fails.  So I run it manually, and got:
ERROR: Command failed: 
 # /usr/bin/dnf builddep --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 31 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=local --disableplugin=spacewalk /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/openjfx-11-11.0.3-0.fc33.src.rpm
No matches found for the following disable plugin patterns: local, spacewalk
fedora                                                                                                                                                                                            14 kB/s | 9.9 kB     00:00    
No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)'


Thoughts?

Comment 2 jiri vanek 2020-02-19 09:49:04 UTC
Is really both
BuildRequires:  pkgconfig(gtk+-2.0)
BuildRequires:  pkgconfig(gtk+-3.0)

needed?

Comment 3 jiri vanek 2020-02-19 10:05:50 UTC
> No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)'
> 
valid for f32+ on f31 dependency is satisfied.  I can run review against f31, but you will need to fix it (thus likely adopt the native maven plugin)

Comment 4 Nicolas De Amicis 2020-02-19 10:10:14 UTC
(In reply to jiri vanek from comment #3)
> > No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)'
> > 
> valid for f32+ on f31 dependency is satisfied.  I can run review against
> f31, but you will need to fix it (thus likely adopt the native maven plugin)

in my f31 mockbuild log, the package is maven-native-components-1.0-0.17.alpha.8.fc31.noarch. This package is orphaned in f32?

Comment 5 Nicolas De Amicis 2020-02-19 10:12:02 UTC
(In reply to jiri vanek from comment #2)
> Is really both
> BuildRequires:  pkgconfig(gtk+-2.0)
> BuildRequires:  pkgconfig(gtk+-3.0)
> 
> needed?

I think yes, because they are two libs: libglassgtk2.so and libglassgtk3.so

Comment 6 jiri vanek 2020-02-19 10:14:28 UTC
btw, there is openjfx package. Do yo  mind to clarify the coexistence of those two? I guess openjfx is, and will rewamin for jdk8, where this openjfx-11 will be for jdk11...and up?
In that moment the weuestion arise, how to deal with those. Will you rename the package with jdk14 and/or 17?
Also I believe your package *is* working with anything we build under java-latest-openjdk, so you should require java >=11, but in that moment the name is wrong.

To have it working flawlessly, we had this in openjdk8 for openjfx(8):
https://koji.fedoraproject.org/koji/rpminfo?rpmID=20202175
That is a binding subpackage (coantains only symlinks). Is something like that wortky for 11+?

 dnf install javafx
Last metadata expiration check: 1:09:27 ago on Wed 19 Feb 2020 09:58:11 AM CET.
Dependencies resolved.
================================================================================
 Package                      Arch     Version                  Repo       Size
================================================================================
Installing:
 java-1.8.0-openjdk-openjfx   x86_64   1:1.8.0.242.b08-0.fc31   updates    34 k
Installing dependencies:
 openjfx                      x86_64   8.0.202-8.b07.fc31       fedora    8.7 M

Transaction Summary
================================================================================
Install  2 Packages


Before review itself, we have to clarify the system integration. From this point of view, you step into a  self-contianed change :)

Comment 7 Nicolas De Amicis 2020-02-19 10:15:43 UTC
(In reply to jiri vanek from comment #1)
> Hi!
> 
> On first glance, the spec looks good. Where the poms come from?
> I tried to run fedora-review but the build fails.  So I run it manually, and
> got:
> ERROR: Command failed: 
>  # /usr/bin/dnf builddep --installroot
> /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 31
> --setopt=deltarpm=False --allowerasing --disableplugin=local
> --disableplugin=spacewalk --disableplugin=local --disableplugin=spacewalk
> /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/openjfx-11-11.
> 0.3-0.fc33.src.rpm
> No matches found for the following disable plugin patterns: local, spacewalk
> fedora                                                                      
> 14 kB/s | 9.9 kB     00:00    
> No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)'
> 
> 
> Thoughts?

I wrote the poms based on the build.gradle file provided by openjfx

Comment 8 jiri vanek 2020-02-19 10:24:25 UTC
fyi https://bugzilla.redhat.com/show_bug.cgi?id=1438673

Comment 9 jiri vanek 2020-02-19 10:26:40 UTC
> 
> I wrote the poms based on the build.gradle file provided by openjfx

I see. Cool. It would be nice to upstream them, and to get rid of that gradle of theirs (me, just wishes:) ). On contrary, gradle have a bit better support for native building. TY!

Comment 10 jiri vanek 2020-02-19 10:35:36 UTC
You maintain opejfx(8) now right?

Is debuginfo/debugsources omitted with reason?  (seeying %global debug_package %{nil} on place)

Comment 11 Nicolas De Amicis 2020-02-19 10:46:07 UTC
(In reply to jiri vanek from comment #6)
> btw, there is openjfx package. Do yo  mind to clarify the coexistence of
> those two? I guess openjfx is, and will rewamin for jdk8, where this
> openjfx-11 will be for jdk11...and up?
> In that moment the weuestion arise, how to deal with those. Will you rename
> the package with jdk14 and/or 17?
> Also I believe your package *is* working with anything we build under
> java-latest-openjdk, so you should require java >=11, but in that moment the
> name is wrong.
> 
> To have it working flawlessly, we had this in openjdk8 for openjfx(8):
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=20202175
> That is a binding subpackage (coantains only symlinks). Is something like
> that wortky for 11+?
> 
>  dnf install javafx
> Last metadata expiration check: 1:09:27 ago on Wed 19 Feb 2020 09:58:11 AM
> CET.
> Dependencies resolved.
> =============================================================================
> ===
>  Package                      Arch     Version                  Repo      
> Size
> =============================================================================
> ===
> Installing:
>  java-1.8.0-openjdk-openjfx   x86_64   1:1.8.0.242.b08-0.fc31   updates   
> 34 k
> Installing dependencies:
>  openjfx                      x86_64   8.0.202-8.b07.fc31       fedora   
> 8.7 M
> 
> Transaction Summary
> =============================================================================
> ===
> Install  2 Packages
> 
> 
> Before review itself, we have to clarify the system integration. From this
> point of view, you step into a  self-contianed change :)

For the coexistence, you are right: openjfx is only for jdk8. openjfx (JavaFX) is included into JDK8 but compiled separately into two projects: openjdk and openjfx. That's why there is a subpackage with only symlinks. Since Java 9 (or 10) openjfx is a separated library. No need to create symlinks.

openjdk-8 and openjdk-11 are long term support. That's why I would like to maintain openjfx libraries for those two JDKs. When the next LTS openjdk will released (openjdk-14) I think a new package could be created. For the intermediate openjdk, I could create a openjfx-latest package? openjfx N runs on openjdk N-1 (dixit Johan Vos openjfx co-lead at JFX Days in Zurich last december)

Comment 12 jiri vanek 2020-02-19 10:57:29 UTC
> 
> For the coexistence, you are right: openjfx is only for jdk8. openjfx
> (JavaFX) is included into JDK8 but compiled separately into two projects:
> openjdk and openjfx. That's why there is a subpackage with only symlinks.
> Since Java 9 (or 10) openjfx is a separated library. No need to create
> symlinks.

Good. thanx!
> 
> openjdk-8 and openjdk-11 are long term support. That's why I would like to
> maintain openjfx libraries for those two JDKs. When the next LTS openjdk
> will released (openjdk-14) I think a new package could be created. For the

nope, openjdk 17 is next LTS

> intermediate openjdk, I could create a openjfx-latest package? openjfx N
> runs on openjdk N-1 (dixit Johan Vos openjfx co-lead at JFX Days in Zurich
> last december)

Is the depndence really so strict? Hard to belive...
If not, I would vote for:
renaming current openjfx to openjfx8
made this package "openjfx" requiring java >= 11
Where the target jdk will be te highest LTS (11 for now) and latest STS(14 in few weeks).

To have it aligned as you are suggesting ojdk 8,11 and latest  x openjfx 8,11, lates is kind offer, but may be very very confusing.

Comment 13 Nicolas De Amicis 2020-02-19 14:05:28 UTC
(In reply to jiri vanek from comment #3)
> > No matching package to install: 'mvn(org.codehaus.mojo:native-maven-plugin)'
> > 
> valid for f32+ on f31 dependency is satisfied.  I can run review against
> f31, but you will need to fix it (thus likely adopt the native maven plugin)

I open a request to adopt maven-native https://pagure.io/releng/issue/9270

Comment 14 jiri vanek 2020-02-19 15:10:54 UTC
thank you, Do you mind to elaborate on:  "openjfx N runs on openjdk N-1 " it is very hard to accept:(

Comment 15 Mario Torre 2020-02-19 15:48:26 UTC
(In reply to jiri vanek from comment #14)
> thank you, Do you mind to elaborate on:  "openjfx N runs on openjdk N-1 " it
> is very hard to accept:(

My understanding is that the N here refers to the latest LTS and is the minimal version it runs on. This means for example that current OpenJFX runs on 11+, once the next LTS will be released, assuming for example this to be OpenJDK 17, OpenJFX will only run on 17+.

Cheers,
Mario

Comment 16 jiri vanek 2020-02-20 11:38:01 UTC
(In reply to Mario Torre from comment #15)
> (In reply to jiri vanek from comment #14)
> > thank you, Do you mind to elaborate on:  "openjfx N runs on openjdk N-1 " it
> > is very hard to accept:(
> 
> My understanding is that the N here refers to the latest LTS and is the
> minimal version it runs on. This means for example that current OpenJFX runs
> on 11+, once the next LTS will be released, assuming for example this to be
> OpenJDK 17, OpenJFX will only run on 17+.
> 
> Cheers,
> Mario

Nicolas, what Mario says leads us to rename of openjx to openjfx8 requiring java <= 1.8.0 and this one to openjfx rewuiring java >=11 as is common for compact packages. WDYT?

Comment 17 Nicolas De Amicis 2020-02-20 13:04:54 UTC
(In reply to jiri vanek from comment #10)
> You maintain opejfx(8) now right?
> 
> Is debuginfo/debugsources omitted with reason?  (seeying %global
> debug_package %{nil} on place)

Yes I'm the maintainer of openjfx(8). 

It's not clear how to generate debuginfo and debugsources. It's mandatory? Could you help me?

Comment 18 Nicolas De Amicis 2020-02-20 13:22:11 UTC
(In reply to jiri vanek from comment #16)
> (In reply to Mario Torre from comment #15)
> > (In reply to jiri vanek from comment #14)
> > > thank you, Do you mind to elaborate on:  "openjfx N runs on openjdk N-1 " it
> > > is very hard to accept:(
> > 
> > My understanding is that the N here refers to the latest LTS and is the
> > minimal version it runs on. This means for example that current OpenJFX runs
> > on 11+, once the next LTS will be released, assuming for example this to be
> > OpenJDK 17, OpenJFX will only run on 17+.
> > 
> > Cheers,
> > Mario
> 
> Nicolas, what Mario says leads us to rename of openjx to openjfx8 requiring
> java <= 1.8.0 and this one to openjfx rewuiring java >=11 as is common for
> compact packages. WDYT?

I agree with that. 

I must to rename openjfx in openjfx8 but for which versions? F30, F31 and F32? Currently the F32 version is in FTBFS https://bugzilla.redhat.com/show_bug.cgi?id=1799832. I need to use maven instead of gradle.
I must make a new package review for this package (renamed from openjfx-11 to openjfx)?

Comment 19 jiri vanek 2020-02-21 10:06:45 UTC
(In reply to Nicolas De Amicis from comment #17)
> (In reply to jiri vanek from comment #10)
> > You maintain opejfx(8) now right?
> > 
> > Is debuginfo/debugsources omitted with reason?  (seeying %global
> > debug_package %{nil} on place)
> 
> Yes I'm the maintainer of openjfx(8). 
> 
> It's not clear how to generate debuginfo and debugsources. It's mandatory?
> Could you help me?

Nope, itis not mandatory. Especially with the grade x maven work you did, and with jni involve, itis definitely not mandatory, and I doubt any reviwer (looks like me) will notisnists.

Comment 20 jiri vanek 2020-02-21 10:16:26 UTC
(In reply to Nicolas De Amicis from comment #18)
> (In reply to jiri vanek from comment #16)
> > (In reply to Mario Torre from comment #15)
> > > (In reply to jiri vanek from comment #14)
> > > > thank you, Do you mind to elaborate on:  "openjfx N runs on openjdk N-1 " it
> > > > is very hard to accept:(
> > > 
> > > My understanding is that the N here refers to the latest LTS and is the
> > > minimal version it runs on. This means for example that current OpenJFX runs
> > > on 11+, once the next LTS will be released, assuming for example this to be
> > > OpenJDK 17, OpenJFX will only run on 17+.
> > > 
> > > Cheers,
> > > Mario
> > 
> > Nicolas, what Mario says leads us to rename of openjx to openjfx8 requiring
> > java <= 1.8.0 and this one to openjfx rewuiring java >=11 as is common for
> > compact packages. WDYT?
> 
> I agree with that. 
> 
> I must to rename openjfx in openjfx8 but for which versions? F30, F31 and
> F32? Currently the F32 version is in FTBFS
> https://bugzilla.redhat.com/show_bug.cgi?id=1799832. I need to use maven
> instead of gradle.
> I must make a new package review for this package (renamed from openjfx-11
> to openjfx)?

That is moving us to utterly different workflow...
Afaik you  can  bump your openjfx pkg to sources from this review in rawhide, and I have to adapt java-1.8.0-openjdk-fx packages to require javafx-8
In meantime you can start review of openjfx8, as new, compact package. Which openjdk8-fx will later depend on. If you fail to fix the FTBS, then it is on to yu to drop it. It happens. I will then just remove openjfx binding from openjdk8. 
This sounds like rawhide only for a while, and backporting should be slow, although to have it in f32 would be useful and nice, I dont think we are meting deadlines, as this is in fact at least self-contained chnage.

Still, wdyt?
I really would like to have wider audience on this:(

Comment 21 Nicolas De Amicis 2020-02-22 20:44:07 UTC
(In reply to jiri vanek from comment #20)
> (In reply to Nicolas De Amicis from comment #18)
> > (In reply to jiri vanek from comment #16)
> > > (In reply to Mario Torre from comment #15)
> > > > (In reply to jiri vanek from comment #14)
> > > > > thank you, Do you mind to elaborate on:  "openjfx N runs on openjdk N-1 " it
> > > > > is very hard to accept:(
> > > > 
> > > > My understanding is that the N here refers to the latest LTS and is the
> > > > minimal version it runs on. This means for example that current OpenJFX runs
> > > > on 11+, once the next LTS will be released, assuming for example this to be
> > > > OpenJDK 17, OpenJFX will only run on 17+.
> > > > 
> > > > Cheers,
> > > > Mario
> > > 
> > > Nicolas, what Mario says leads us to rename of openjx to openjfx8 requiring
> > > java <= 1.8.0 and this one to openjfx rewuiring java >=11 as is common for
> > > compact packages. WDYT?
> > 
> > I agree with that. 
> > 
> > I must to rename openjfx in openjfx8 but for which versions? F30, F31 and
> > F32? Currently the F32 version is in FTBFS
> > https://bugzilla.redhat.com/show_bug.cgi?id=1799832. I need to use maven
> > instead of gradle.
> > I must make a new package review for this package (renamed from openjfx-11
> > to openjfx)?
> 
> That is moving us to utterly different workflow...
> Afaik you  can  bump your openjfx pkg to sources from this review in
> rawhide, and I have to adapt java-1.8.0-openjdk-fx packages to require
> javafx-8
> In meantime you can start review of openjfx8, as new, compact package. Which
> openjdk8-fx will later depend on. If you fail to fix the FTBS, then it is on
> to yu to drop it. It happens. I will then just remove openjfx binding from
> openjdk8. 
> This sounds like rawhide only for a while, and backporting should be slow,
> although to have it in f32 would be useful and nice, I dont think we are
> meting deadlines, as this is in fact at least self-contained chnage.
> 
> Still, wdyt?
> I really would like to have wider audience on this:(

Sorry, correct me if I misunderstood: I commit into package openjfx the code from this review (openjfx 11) in rawhide. In meantime I fix the FTBFS of the package openjfx (openjfx 8) in F32. Finally, I make  a package review for a new openjfx8 package and I merge into the code for openjfx 8 and you drive the modifications needed for java-1.8.0-openjdk-openjfx?

Comment 22 jiri vanek 2020-02-24 09:32:01 UTC
Moreover yes.
>  I commit into package openjfx the code from this review (openjfx 11) in rawhide.
In that moment I have to disable openjdk8 bindings.

> In meantime I fix the FTBFS of the package openjfx (openjfx 8) in F32.
Yes, unless you wish to have both openjfx-8 and openjfx(-11) in f32
In that case the FTBS failure can be solved during openjfx-8 review. 
But I doubt that :) We have to start in rawhide, and are unlikely to make it for f32.

Probably the most correct way is to go as self-contained change for f33, to get a proper adudience on the topic.

> I make  a package review for a new openjfx8 package and I merge into the code for openjfx 8 and you drive the modifications needed for java-1.8.0-openjdk-openjfx

yes

Comment 23 jiri vanek 2020-03-04 09:29:51 UTC
Small update. We will (try to) move jdk11 to system jdk in f33

Comment 24 Nicolas De Amicis 2020-03-04 09:49:32 UTC
(In reply to jiri vanek from comment #23)
> Small update. We will (try to) move jdk11 to system jdk in f33

Thanks for the update. maven-native is unretired today, I will commit and publish the new version soon. I'm currently working and resolve the FTBFS on openjfx8. I will also commit the code of openjfx11 into rawhide of the project openjfx like as discussed.

Comment 25 Nicolas De Amicis 2020-08-04 07:34:54 UTC
as discussed, openjfx8 for javafx8 and openjfx for javafx11 are in rawhide


Note You need to log in before you can comment on or make changes to this bug.