Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Michael Ennen]

Re-familiarizing myself with what javapackager offers, it seems the
following JavaFX related
features are present:

1.) The conversion of CSS to binary CSS
2.) The ability to specify a preloader
3.) the ability to specify the JavaFX Application class

The first one seems like a bit of feature-creep and could be replaced by
some other build
tool if third party developers really need that feature. They could
probably even use something
like maven-exec-plugin to manually call such a converter. Let's set this
one aside, then.

The second and third one are important for correctly launching a JavaFX
application. I would
think that in order for these to be easily accomplished flags would need to
be present in
"jpackager" for specifying them (namely, the preloader and Application
class). Otherwise
jpackager would need to do some "reflection" to try and determine whether
or not JavaFX is
being used (maybe by checking for its presence on the module path?) and
then, if so, get
the appropriate preloader and application class.

I only mention this because the JEP proposal specifically states
"JavaFX-specific features"
under "Non-Goals" but this might make things more complicated than they
need to be
in those two areas I mentioned above.

Other then that, this looks good to me and I think having a replacement for
javapackager
is a good idea.

Thanks,
Michael Ennen

On Thu, May 31, 2018 at 1:56 PM, Kevin Rushforth  wrote:

> The existing javapackager doesn't really know much about JavaFX as it is,
> now that applet and Web Start are gone. I am not aware of anything that
> would preclude packaging up a JavaFX application. We will certainly test
> the ability to package up a JavaFX application.
>
> As for the schedule, I agree it isn't ideal, but it's too late for JDK 11.
>
> -- Kevin
>
>
>
> On 5/31/2018 1:25 PM, Michael Paus wrote:
>
>> Hi,
>>
>> is it possible to get a clear statement on whether it will be possible to
>> package a JavaFX application with the new packager in a similar way as it
>> is possible right now with the old packager? The texts are a little bit
>> vague there. I just don't know whether it is possible to create a packager
>> which does not know anything about the GUI framework which has been used by
>> an application.
>>
>> I would also like to express my concerns about the schedule. The next
>> Java release (11) will be an LTS release and that means that there will not
>> be any packager for all those people who will have to stick with this
>> release for a long time. This is a huge step backward for Java because
>> there is then no good deployment technology anymore for a long time.
>>
>> Michael
>>
>> Am 31.05.18 um 02:11 schrieb Kevin Rushforth:
>>
>>> I just sent an email to the core-libs-dev alias [1] proposing a new
>>> Packaging Tool as a replacement for javapackager. If you are interested in
>>> this JEP, you can follow and participate in the discussion there.
>>>
>>> -- Kevin
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-Ma
>>> y/053503.html
>>>
>>>
>>
>

Re: OpenJFX code review policies, etc.

[Kevin Rushforth]

On 5/24/2018 9:31 AM, Nir Lisker wrote:

Thanks for the detailed plan Kevin,

I will provide an initial list of reviewers to the registrar based
on past contributions, and also recognizing Committers who have
become experts in their area.


It will be a good idea to list the reviewers/experts (names and mail) 
according to their field, as done in the outdated Wiki [1]. This way 
contributors know who to address in a review request mail. Currently, 
I need to filter a subcomponent in JIRA and see who provides the fixes 
there to know who to ask.


That is a good idea. Reviving this page after we have the initial list 
of reviewers seems like a good idea.




B. We need to set formal guidelines for becoming a Reviewer. The
JDK uses a threshold of 32 significant contributions. While we
don't want to relax it too much, one thing I have been discussing
informally with a few people is that a Committer with, say, 24
commits, who regularly participates in reviews, offering good
feedback, might be just a good a reviewer (maybe even better) than
someone with 32 commits who rarely, if ever, provides feedback on
proposed bug fixes. I'm open for suggestions here.


Continuing the point above, it makes sense to me that a Reviewer role 
is assigned per field (whether a "field" is module, a set of packages 
or something else). While formally we need to give a list of Reviewers 
for OpenJFX, practically I don't think a Reviewer who contributed 40 
out of his 42 commits to javafx.base can (and probably wouldn't 
anyway) Review in javafx.web. What I'm getting at is that whatever the 
threshold numbers are, it makes sense, at least informally, to count 
per field. If I submit 5 contributions per module and pass the 
threshold, what exactly am I qualified to Review?



That's an interesting, and accurate, observation. It sort of goes along 
with your earlier point about having areas of expertise.



Granted, the threshold numbers includes familiarizing oneself with 
code patterns and tools which are global to the project, so to become 
a Reviewer in a 2nd field takes much less effort than the first time.


This is just a point I wanted to make about the Reviewer role. We 
don't have to change formal policies.


I propose that a New Feature, API addition, or behavioral change
must be reviewed / approved by a "lead". 



Can you give the guidelines by which a lead reviews / approves one of 
the above?


Ultimately it will be a judgment call. I can't speak for Johan, but what 
I usually do is see whether the proposed feature is a good fit for the 
API, doesn't raise any compatibility concerns, is supportable, testable, 
etc., and then get to the more detailed review of the spec and API 
additions themselves.



D. All code review policies outlined above in #2 were followed
prior to the PR being approved and merged into the develop branch
on GitHub. This includes sending email to openjfx-dev when you
first make a PR that you intend to have merged into the develop
branch to give other reviewers who may not be watching all PRs a
chance to comment before it is merged.


I would hope that the people in openjfx-dev who are not watching all 
PRs will have a chance to comment before the work starts, and not when 
the work is done and before it's merged. Visiting the mirror from time 
to time reveals to me PRs that weren't mentioned on the mailing list. 
Those PRs might be in conflict with work that isn't visible on GitHub. 
Iv'e brought it up in a past discussion about the mirror - we need to 
centralize the discussion medium. It's the normal price to pay for 
synchronization.




A fair point, which is why I proposed that one of the requirements for 
having this fast track review includes "... sending email to openjfx-dev 
when you first make a PR that you intend to have merged into the 
develop" so that those who are interested in a particular bug will know 
that a fix is under review.


Thanks.

-- Kevin



- Nir

[1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership 



On Thu, May 24, 2018 at 1:16 AM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


To: OpenJFX Developers

As I mentioned in a message last week [1] I would like to restart
the discussion we started a few months ago [2] around making it
easier to contribute code to OpenJFX. To this end, I like to make
some concrete proposals around code review / API review policies.

Before getting to the details, I would like to acknowledge Gluon's
contributions to the OpenJFX project, specifically those of Johan
Vos. I am pleased to announce an expanded role for Johan Vos in
the OpenJFX project. I would like to announce that starting now,
Johan is effectively a co-lead for the purposes of setting
direction, and approving new features for the Project.

The short version of t

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Kevin Rushforth]

The existing javapackager doesn't really know much about JavaFX as it 
is, now that applet and Web Start are gone. I am not aware of anything 
that would preclude packaging up a JavaFX application. We will certainly 
test the ability to package up a JavaFX application.


As for the schedule, I agree it isn't ideal, but it's too late for JDK 11.

-- Kevin


On 5/31/2018 1:25 PM, Michael Paus wrote:

Hi,

is it possible to get a clear statement on whether it will be possible 
to package a JavaFX application with the new packager in a similar way 
as it is possible right now with the old packager? The texts are a 
little bit vague there. I just don't know whether it is possible to 
create a packager which does not know anything about the GUI framework 
which has been used by an application.


I would also like to express my concerns about the schedule. The next 
Java release (11) will be an LTS release and that means that there 
will not be any packager for all those people who will have to stick 
with this release for a long time. This is a huge step backward for 
Java because there is then no good deployment technology anymore for a 
long time.


Michael

Am 31.05.18 um 02:11 schrieb Kevin Rushforth:
I just sent an email to the core-libs-dev alias [1] proposing a new 
Packaging Tool as a replacement for javapackager. If you are 
interested in this JEP, you can follow and participate in the 
discussion there.


-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Michael Paus]

Hi,

is it possible to get a clear statement on whether it will be possible 
to package a JavaFX application with the new packager in a similar way 
as it is possible right now with the old packager? The texts are a 
little bit vague there. I just don't know whether it is possible to 
create a packager which does not know anything about the GUI framework 
which has been used by an application.


I would also like to express my concerns about the schedule. The next 
Java release (11) will be an LTS release and that means that there will 
not be any packager for all those people who will have to stick with 
this release for a long time. This is a huge step backward for Java 
because there is then no good deployment technology anymore for a long time.


Michael

Am 31.05.18 um 02:11 schrieb Kevin Rushforth:
I just sent an email to the core-libs-dev alias [1] proposing a new 
Packaging Tool as a replacement for javapackager. If you are 
interested in this JEP, you can follow and participate in the 
discussion there.


-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html