Looks like the page
https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow is
outdated.
It links to the BitBucket repo and mentions that one of the ways to provide
a patch is to create a pull request on BitBucket.
On 18 March 2015 at 05:51, Jonathan Giles jonathan.gi...@oracle.com
There was a mirror, but it was unofficial and one-way (OpenJDK -
BitBucket). I believe (although my memory may be failing me) that it was
operated by Danno, so he might have more to say.
In regards to fork / pull-request vs patch-file, I have no arguments
there. Of course, OpenJFX is part of
Kevin, Chien and David,
Please review my fix for this Mac Stage focus close issue. The Mac OSX
internals were forcing a callback event onto a non-focused window, and
this preemptively asserts focus before allowing the event through.
--morris
WEBREV -
Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror
for your own experiments, that is certainly something you could do
(subject to the GPLv2 + CLASSPATH license terms).
For those patches to then be incorporated into the openjfx repos on
hg.openjdk.java.net they need to go
Wouldn't it be possible for the OpenJFX team to officially maintain a mirror at
BitBucket themselves and use the same criteria for accepting a pull-request as
for accepting a patch-file? Then you're sure that you can synchronize it with
the main repositories without any legal or quality issues.
Thank you, David, for explaining all that is involved to us desktop-types.
:-)
Neil
From: David Hill david.h...@oracle.com
To: openjfx-dev@openjdk.java.net,
Date: 03/17/2015 02:40 PM
Subject:Re: libjfxmedia.so on armv6hf?
Sent by:openjfx-dev
On 3/17/15, 8:04 AM, Erik De Rijcke wrote:
Why are there limitations on the embedded port of javafx to begin with?
Are there technical reasons for it?
Quite a few actually
The embedded platforms have quite a few features that make them difficult.
(and I have the bruises to prove it :-)
Sorry, I'm a bit confused:
On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:
Media and web have not ever been supported or delivered on linux-arm.
So it is possible to build libjfxmedia.so for Linux armv6hf using just
what's in the rt repo?
Thanks,
Chris
On Tue, March 17, 2015 14:46,
Hi Kevin and Jim,
Please review the proposed fix:
JIRA: https://javafx-jira.kenai.com/browse/RT-40245
Webrev: http://cr.openjdk.java.net/~ckyang/RT-40245/webrev.00/
Thanks,
- Chien
Since this is Mac glass code, Morris needs to review it as well.
-- Kevin
Chien Yang wrote:
Hi Kevin and Jim,
Please review the proposed fix:
JIRA: https://javafx-jira.kenai.com/browse/RT-40245
Webrev: http://cr.openjdk.java.net/~ckyang/RT-40245/webrev.00/
Thanks,
- Chien
Correct.
-- Jonathan
On 18 March 2015 13:19:21 GMT+13:00, Tomas Mikula tomas.mik...@gmail.com
wrote:
But we still need this one-way mirror, from which users can fork,
right? My assumption is that bitbucket will not keep track of how much
you diverged from the OpenJDK repo you initially cloned.
But we still need this one-way mirror, from which users can fork,
right? My assumption is that bitbucket will not keep track of how much
you diverged from the OpenJDK repo you initially cloned. It will,
however, tell you how much you diverged from a bitbucket repo that you
forked.
On Tue, Mar 17,
There is no issue with members of the community using BitBucket to
develop their patches. I just don't think it is a wise use of our
limited time to maintain a mirror. This seems something that interested
community members can do if they want. The main issue is as Kevin
mentioned - someone has
Legal issues could be resolved by requiring a signed OCA before each
pull request is merged. But anyway, if OpenJDK project does not accept
pull requests, who is going to create the patches? If patches are
painful for individual developers, they are going to be super painful
for the person who is
BitBucket supports generation of patches from pull requests. My
suggestion was that community members who wanted to use BitBucket to
collaborate and / or easily keep their work current with the repo could
do so, and when they create their pull request, they can have bitbucket
generate the
Why didn't you target drm/kms gl approach? I realise not all platforms
support this, but it would greatly extend the number of supported
(embedded) platforms in a generic way. A quick google search seems to
indicate that the sgx530 (BBB) has a kms driver as does the vivante (imx6).
An RPi drm/kms
Why are there limitations on the embedded port of javafx to begin with?
Are there technical reasons for it?
If you think about it, It's arm, so it's embedded. It's x86 so it's
desktop doesn't make much sense... (atom is embedded, and there are arm
windows netbooks that are not).
Anyway, as a
Not sure what missing stuff you are referring to. All of the JavaFX
sources for embedded are in the rt repo on openjfx.
-- Kevin
Chris Newland wrote:
Hi Kevin,
Is there any chance Oracle can release all the missing ARM32 stuff and let
the community have a go at getting it to work or are
On 18.03.2015 01:03, Tomas Mikula wrote:
Legal issues could be resolved by requiring a signed OCA before each
pull request is merged.
Or we could simply require changes to come in the way we do now and
avoid having to deal with another set of side issues altogether.
A development model
then you have to spend weeks sorting out who contributed to the files in
the pull request
Is it common to have multiple authors for a single pull request?
how to contact them, if they are covered under the OCA
Google [1] (googlebot), Mozilla [2] (rust-highfive robot) and Microsoft [3]
(msftclas
20 matches
Mail list logo
