Hi Phil,
Thanks for having a look at the changes.
I have little difficulty in understanding your question.
Are you referring to the sun.font.SunFontManager initialization?
I am asking as it is not evident from the code changes that I have done as
part of this webrev.
Request
Sorry for the delay in responding. I was traveling when this was sent
and barely able to keep up with urgent email / tasks.
Most of what you suggest below seems good. My only concern is whether
the "on demand" evaluation will have any side effects. Conceptually, it
seems like the right thing
As I said before, we need to be careful where the discussion is made. PRs
on GitHub have their own thread and there's also the mailing list. Maybe
someone from Oracle already has done work related to the PR, and this will
only be known if a JBS issue is submitted or a mailing list thread is
Thanks for the info. I update the bug report with this information, and
marked it as a regression (introduced in 9).
-- Kevin
Nir Lisker wrote:
I tested the issue. It is not present in 1.8.0_152-b16, but it is present
in 9+181 and 10-ea+37.
- Nir
As far as the bug goes, I think it would be better to do it the other
way around. If we adopt a policy that a PR should reference a bug in
JBS, then that part of the problem will go away. I'm not convinced that
merging a random PR, for what is essentially just "a good idea" if it
isn't backed
Having a bot that creates a webrev, verifies OCA is signed for the commit
author,
and a generates a JBS/java bug report template would be ideal IMO.
We can use something like AWS Lambda that runs every X minutes and checks
for PRs to the openjdk-jfx GitHub repository. If a new PR is seen, or a PR
Thank you!
My concerns (not complaints) and questions:
1. Developer forks the github repo, enhances it, and creates a PR.
2. He discusses it with a committer, and eventually the PR is accepted.
As I said before, we need to be careful where the discussion is made. PRs
on GitHub have their own
Hi Michael,
That is great!
Using Travis CI will clearly help keeping the project in a good shape.
I added a comment, and I hope others with more experience with Travis than
me will jump in.
Thanks,
- Johan
On Wed, Feb 14, 2018 at 9:21 PM Michael Ennen wrote:
> Thanks
Thanks for taking the initiative, Johan.
I have opened two PRs that add support for Travis CI and Appveyor
continuous integration (which can be used to build pull requests and
the master branch after a merge (or using a cron-timer) automatically).
This will allow sandboxers to test their code on
Johan,
Thank‘s so much for all the effort you‘ve put into OpenJFX...it is highly
appreciated
Keep up the great work,
Cheers,
Gerrit
Gerrit Grunwald
Westfalenstr. 93
48165 Münster
Germany
tel: +49 (0)2501 24321
mob: +49 (0)171 1745350
web: http://www.harmonic-code.org
Am 14. Feb. 2018,
I tested the issue. It is not present in 1.8.0_152-b16, but it is present
in 9+181 and 10-ea+37.
- Nir
Nice! Thanks for your hard work on this, Johan.
-- Kevin
Johan Vos wrote:
Hi,
I did 2 things:
* I talked to the fine and great people at AdoptOpenJDK (
https://adoptopenjdk.net/) and they are happy to have their build farm
being used to create OpenJFX modules (including the native
Hi,
I did 2 things:
* I talked to the fine and great people at AdoptOpenJDK (
https://adoptopenjdk.net/) and they are happy to have their build farm
being used to create OpenJFX modules (including the native libraries). We
are currently looking at the scripts that are being used for syncing and
Hi,
I'm on 162 and the process and I have an old machine without the latest
OS-X version and running the build there works.
Running the completely same bits on the latest and greatest OS-X and the
same Java version on my main work machine it fails with exactly the line
given by Michael.
Tom
On
14 matches
Mail list logo