Re: OpenJFX mirror at BitBucket?

[Benjamin Gudehus]

>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 bot) solve this issue, by using automatic bots that welcome the
contributors and keep an list of already signed CLAs.

[1] https://github.com/Polymer/polymer/pull/1247#issuecomment-76956855
[2] https://github.com/rust-lang/rust/pull/23466#issuecomment-82750848
[3] https://github.com/Microsoft/TypeScript/pull/2376

Regards,
Benjamin

On Wed, Mar 18, 2015 at 6:31 AM, dalibor topic 
wrote:

> 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 where individual contributors work on their own
> individual changes, and then submit them separately is much easier to deal
> with for reviewers than one where some random things happen on bitbucket,
> someone after a while sends in a random pull request and then you have to
> spend weeks sorting out who contributed to the files in the pull request,
> how to contact them, if they are covered under the OCA, etc.
>
> cheers,
> dalibor topic
> --
>  Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961
> 
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> Geschäftsführer: Jürgen Kunz
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
>
>  Oracle is committed to developing
> practices and products that help protect the environment
>

Re: OpenJFX mirror at BitBucket?

[dalibor topic]

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 where individual contributors work on their own 
individual changes, and then submit them separately is much easier to 
deal with for reviewers than one where some random things happen on 
bitbucket, someone after a while sends in a random pull request and then 
you have to spend weeks sorting out who contributed to the files in the 
pull request, how to contact them, if they are covered under the OCA, etc.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: OpenJFX mirror at BitBucket?

[Anirvan Sarkar]

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  wrote:

> Correct.
> -- Jonathan
>
> On 18 March 2015 13:19:21 GMT+13:00, Tomas Mikula 
> 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. It will,
> >however, tell you how much you diverged from a bitbucket repo that you
> >forked.
> >
> >On Tue, Mar 17, 2015 at 8:09 PM, Jonathan Giles
> > wrote:
> >> 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 patch
> >file
> >> for submission 'the old fashioned way'.
> >>
> >> -- Jonathan
> >>
> >> On 18/03/2015 1:03 p.m., Tomas Mikula wrote:
> >>>
> >>> 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 supposed to get the accepted PRs back to
> >>> OpenJDK.
> >>>
> >>> OTOH, one-way mirrors should be easy enough to maintain by anyone
> >who
> >>> has access to a server where they can set up a cron task to
> >>> periodically pull from OpenJDK repos and push to bitbucket repos.
> >>> Whoever forks the mirror and makes changes would still have to
> >submit
> >>> patches directly to OpenJDK.
> >>>
> >>> Tomas
> >>>
> >>> On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles
> >>>  wrote:
> 
>  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
>  to
>  submit the patch officially, and that someone has to have signed an
> >OCA
>  stating that they are owners of the code and IP being submitted. It
> >would
>  pay to very carefully track who has contributed code to a certain
> >patch
>  file, as all contributors will need to have signed an OCA.
> 
>  -- Jonathan
> 
> 
>  On 18/03/2015 11:12 a.m., Florian Brunner wrote:
> >
> > 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.
> >
> > The contributors could link their forks and pull-requests in JIRA
> >for
> > documentation purposes.
> >
> > It would really be great if we could move on with this.
> >
> > -Florian
> >
> > Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
> >>
> >> 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 through the existing openjdk
> >> mechanism (which requires a signed OCA) as patches / webrevs,
> >just like
> >> any other openjdk project. We cannot take patches directly from a
> >> BitBucket repo.
> >>
> >> -- Kevin
> >>
> >> Jonathan Giles wrote:
> >>>
> >>> 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 the OpenJDK, and therefore
> >makes
> >>> use of the OpenJDK infrastructure. My main point is that any
> >movement
> >>> regarding infrastructure is guided by an over-arching
> >infrastructure
> >>> team, in conjunction with the OpenJDK masters. OpenJFX can't
> >work
> >>> independent of this.
> >>>
> >>> -- Jonathan
> >>>
> >>> On 18/03/2015 10:50 a.m., Florian Brunner wrote:
> 
>  Hi,
> 
>  AFAIK there is/ was a mirror of OpenJFX at BitBucket.
> 
>  I think 

Re: Code Review Request For RT-40245: Regression: Mac (prism-sw) rendering is corrupted

[Kevin Rushforth]

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

Code Review Request For RT-40245: Regression: Mac (prism-sw) rendering is corrupted

[Chien Yang]

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

Re: OpenJFX mirror at BitBucket?

[Jonathan Giles]

Correct.
-- Jonathan

On 18 March 2015 13:19:21 GMT+13:00, Tomas Mikula  
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. It will,
>however, tell you how much you diverged from a bitbucket repo that you
>forked.
>
>On Tue, Mar 17, 2015 at 8:09 PM, Jonathan Giles
> wrote:
>> 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 patch
>file
>> for submission 'the old fashioned way'.
>>
>> -- Jonathan
>>
>> On 18/03/2015 1:03 p.m., Tomas Mikula wrote:
>>>
>>> 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 supposed to get the accepted PRs back to
>>> OpenJDK.
>>>
>>> OTOH, one-way mirrors should be easy enough to maintain by anyone
>who
>>> has access to a server where they can set up a cron task to
>>> periodically pull from OpenJDK repos and push to bitbucket repos.
>>> Whoever forks the mirror and makes changes would still have to
>submit
>>> patches directly to OpenJDK.
>>>
>>> Tomas
>>>
>>> On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles
>>>  wrote:

 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
 to
 submit the patch officially, and that someone has to have signed an
>OCA
 stating that they are owners of the code and IP being submitted. It
>would
 pay to very carefully track who has contributed code to a certain
>patch
 file, as all contributors will need to have signed an OCA.

 -- Jonathan


 On 18/03/2015 11:12 a.m., Florian Brunner wrote:
>
> 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.
>
> The contributors could link their forks and pull-requests in JIRA
>for
> documentation purposes.
>
> It would really be great if we could move on with this.
>
> -Florian
>
> Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
>>
>> 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 through the existing openjdk
>> mechanism (which requires a signed OCA) as patches / webrevs,
>just like
>> any other openjdk project. We cannot take patches directly from a
>> BitBucket repo.
>>
>> -- Kevin
>>
>> Jonathan Giles wrote:
>>>
>>> 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 the OpenJDK, and therefore
>makes
>>> use of the OpenJDK infrastructure. My main point is that any
>movement
>>> regarding infrastructure is guided by an over-arching
>infrastructure
>>> team, in conjunction with the OpenJDK masters. OpenJFX can't
>work
>>> independent of this.
>>>
>>> -- Jonathan
>>>
>>> On 18/03/2015 10:50 a.m., Florian Brunner wrote:

 Hi,

 AFAIK there is/ was a mirror of OpenJFX at BitBucket.

 I think the URL was https://bitbucket.org/openjfxmirrors, but
>it's
 not valid
 anymore.

 Is there still a mirror of OpenJFX at BitBucket?

 A fork/pull-request workflow is state-of-the-art nowadays in
>software
 development and way better than a patch-file based workflow
>IMHO.

 It would be great to have such a fork/pull-request workflow
>also for
 OpenJFX!

 -Florian


>>

Re: OpenJFX mirror at BitBucket?

[Tomas Mikula]

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, 2015 at 8:09 PM, Jonathan Giles
 wrote:
> 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 patch file
> for submission 'the old fashioned way'.
>
> -- Jonathan
>
> On 18/03/2015 1:03 p.m., Tomas Mikula wrote:
>>
>> 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 supposed to get the accepted PRs back to
>> OpenJDK.
>>
>> OTOH, one-way mirrors should be easy enough to maintain by anyone who
>> has access to a server where they can set up a cron task to
>> periodically pull from OpenJDK repos and push to bitbucket repos.
>> Whoever forks the mirror and makes changes would still have to submit
>> patches directly to OpenJDK.
>>
>> Tomas
>>
>> On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles
>>  wrote:
>>>
>>> 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
>>> to
>>> submit the patch officially, and that someone has to have signed an OCA
>>> stating that they are owners of the code and IP being submitted. It would
>>> pay to very carefully track who has contributed code to a certain patch
>>> file, as all contributors will need to have signed an OCA.
>>>
>>> -- Jonathan
>>>
>>>
>>> On 18/03/2015 11:12 a.m., Florian Brunner wrote:

 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.

 The contributors could link their forks and pull-requests in JIRA for
 documentation purposes.

 It would really be great if we could move on with this.

 -Florian

 Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
>
> 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 through the existing openjdk
> mechanism (which requires a signed OCA) as patches / webrevs, just like
> any other openjdk project. We cannot take patches directly from a
> BitBucket repo.
>
> -- Kevin
>
> Jonathan Giles wrote:
>>
>> 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 the OpenJDK, and therefore makes
>> use of the OpenJDK infrastructure. My main point is that any movement
>> regarding infrastructure is guided by an over-arching infrastructure
>> team, in conjunction with the OpenJDK masters. OpenJFX can't work
>> independent of this.
>>
>> -- Jonathan
>>
>> On 18/03/2015 10:50 a.m., Florian Brunner wrote:
>>>
>>> Hi,
>>>
>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket.
>>>
>>> I think the URL was https://bitbucket.org/openjfxmirrors, but it's
>>> not valid
>>> anymore.
>>>
>>> Is there still a mirror of OpenJFX at BitBucket?
>>>
>>> A fork/pull-request workflow is state-of-the-art nowadays in software
>>> development and way better than a patch-file based workflow IMHO.
>>>
>>> It would be great to have such a fork/pull-request workflow also for
>>> OpenJFX!
>>>
>>> -Florian
>>>
>>>
>

Re: OpenJFX mirror at BitBucket?

[Jonathan Giles]

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 patch file for submission 'the old fashioned way'.


-- Jonathan

On 18/03/2015 1:03 p.m., Tomas Mikula wrote:

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 supposed to get the accepted PRs back to
OpenJDK.

OTOH, one-way mirrors should be easy enough to maintain by anyone who
has access to a server where they can set up a cron task to
periodically pull from OpenJDK repos and push to bitbucket repos.
Whoever forks the mirror and makes changes would still have to submit
patches directly to OpenJDK.

Tomas

On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles
 wrote:

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 to
submit the patch officially, and that someone has to have signed an OCA
stating that they are owners of the code and IP being submitted. It would
pay to very carefully track who has contributed code to a certain patch
file, as all contributors will need to have signed an OCA.

-- Jonathan


On 18/03/2015 11:12 a.m., Florian Brunner wrote:

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.

The contributors could link their forks and pull-requests in JIRA for
documentation purposes.

It would really be great if we could move on with this.

-Florian

Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:

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 through the existing openjdk
mechanism (which requires a signed OCA) as patches / webrevs, just like
any other openjdk project. We cannot take patches directly from a
BitBucket repo.

-- Kevin

Jonathan Giles wrote:

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 the OpenJDK, and therefore makes
use of the OpenJDK infrastructure. My main point is that any movement
regarding infrastructure is guided by an over-arching infrastructure
team, in conjunction with the OpenJDK masters. OpenJFX can't work
independent of this.

-- Jonathan

On 18/03/2015 10:50 a.m., Florian Brunner wrote:

Hi,

AFAIK there is/ was a mirror of OpenJFX at BitBucket.

I think the URL was https://bitbucket.org/openjfxmirrors, but it's
not valid
anymore.

Is there still a mirror of OpenJFX at BitBucket?

A fork/pull-request workflow is state-of-the-art nowadays in software
development and way better than a patch-file based workflow IMHO.

It would be great to have such a fork/pull-request workflow also for
OpenJFX!

-Florian

Re: OpenJFX mirror at BitBucket?

[Tomas Mikula]

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 supposed to get the accepted PRs back to
OpenJDK.

OTOH, one-way mirrors should be easy enough to maintain by anyone who
has access to a server where they can set up a cron task to
periodically pull from OpenJDK repos and push to bitbucket repos.
Whoever forks the mirror and makes changes would still have to submit
patches directly to OpenJDK.

Tomas

On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles
 wrote:
> 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 to
> submit the patch officially, and that someone has to have signed an OCA
> stating that they are owners of the code and IP being submitted. It would
> pay to very carefully track who has contributed code to a certain patch
> file, as all contributors will need to have signed an OCA.
>
> -- Jonathan
>
>
> On 18/03/2015 11:12 a.m., Florian Brunner wrote:
>>
>> 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.
>>
>> The contributors could link their forks and pull-requests in JIRA for
>> documentation purposes.
>>
>> It would really be great if we could move on with this.
>>
>> -Florian
>>
>> Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
>>>
>>> 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 through the existing openjdk
>>> mechanism (which requires a signed OCA) as patches / webrevs, just like
>>> any other openjdk project. We cannot take patches directly from a
>>> BitBucket repo.
>>>
>>> -- Kevin
>>>
>>> Jonathan Giles wrote:

 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 the OpenJDK, and therefore makes
 use of the OpenJDK infrastructure. My main point is that any movement
 regarding infrastructure is guided by an over-arching infrastructure
 team, in conjunction with the OpenJDK masters. OpenJFX can't work
 independent of this.

 -- Jonathan

 On 18/03/2015 10:50 a.m., Florian Brunner wrote:
>
> Hi,
>
> AFAIK there is/ was a mirror of OpenJFX at BitBucket.
>
> I think the URL was https://bitbucket.org/openjfxmirrors, but it's
> not valid
> anymore.
>
> Is there still a mirror of OpenJFX at BitBucket?
>
> A fork/pull-request workflow is state-of-the-art nowadays in software
> development and way better than a patch-file based workflow IMHO.
>
> It would be great to have such a fork/pull-request workflow also for
> OpenJFX!
>
> -Florian
>
>

Re: OpenJFX mirror at BitBucket?

[Jonathan Giles]

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 to submit the patch officially, and that someone 
has to have signed an OCA stating that they are owners of the code and 
IP being submitted. It would pay to very carefully track who has 
contributed code to a certain patch file, as all contributors will need 
to have signed an OCA.


-- Jonathan

On 18/03/2015 11:12 a.m., Florian Brunner wrote:

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.

The contributors could link their forks and pull-requests in JIRA for
documentation purposes.

It would really be great if we could move on with this.

-Florian

Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:

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 through the existing openjdk
mechanism (which requires a signed OCA) as patches / webrevs, just like
any other openjdk project. We cannot take patches directly from a
BitBucket repo.

-- Kevin

Jonathan Giles wrote:

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 the OpenJDK, and therefore makes
use of the OpenJDK infrastructure. My main point is that any movement
regarding infrastructure is guided by an over-arching infrastructure
team, in conjunction with the OpenJDK masters. OpenJFX can't work
independent of this.

-- Jonathan

On 18/03/2015 10:50 a.m., Florian Brunner wrote:

Hi,

AFAIK there is/ was a mirror of OpenJFX at BitBucket.

I think the URL was https://bitbucket.org/openjfxmirrors, but it's
not valid
anymore.

Is there still a mirror of OpenJFX at BitBucket?

A fork/pull-request workflow is state-of-the-art nowadays in software
development and way better than a patch-file based workflow IMHO.

It would be great to have such a fork/pull-request workflow also for
OpenJFX!

-Florian

Re: OpenJFX mirror at BitBucket?

[Florian Brunner]

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.

The contributors could link their forks and pull-requests in JIRA for 
documentation purposes.

It would really be great if we could move on with this.

-Florian

Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
> 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 through the existing openjdk
> mechanism (which requires a signed OCA) as patches / webrevs, just like
> any other openjdk project. We cannot take patches directly from a
> BitBucket repo.
> 
> -- Kevin
> 
> Jonathan Giles wrote:
> > 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 the OpenJDK, and therefore makes
> > use of the OpenJDK infrastructure. My main point is that any movement
> > regarding infrastructure is guided by an over-arching infrastructure
> > team, in conjunction with the OpenJDK masters. OpenJFX can't work
> > independent of this.
> > 
> > -- Jonathan
> > 
> > On 18/03/2015 10:50 a.m., Florian Brunner wrote:
> >> Hi,
> >> 
> >> AFAIK there is/ was a mirror of OpenJFX at BitBucket.
> >> 
> >> I think the URL was https://bitbucket.org/openjfxmirrors, but it's
> >> not valid
> >> anymore.
> >> 
> >> Is there still a mirror of OpenJFX at BitBucket?
> >> 
> >> A fork/pull-request workflow is state-of-the-art nowadays in software
> >> development and way better than a patch-file based workflow IMHO.
> >> 
> >> It would be great to have such a fork/pull-request workflow also for
> >> OpenJFX!
> >> 
> >> -Florian

Re: OpenJFX mirror at BitBucket?

[Kevin Rushforth]

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 through the existing openjdk 
mechanism (which requires a signed OCA) as patches / webrevs, just like 
any other openjdk project. We cannot take patches directly from a 
BitBucket repo.


-- Kevin



Jonathan Giles wrote:
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 the OpenJDK, and therefore makes 
use of the OpenJDK infrastructure. My main point is that any movement 
regarding infrastructure is guided by an over-arching infrastructure 
team, in conjunction with the OpenJDK masters. OpenJFX can't work 
independent of this.


-- Jonathan

On 18/03/2015 10:50 a.m., Florian Brunner wrote:

Hi,

AFAIK there is/ was a mirror of OpenJFX at BitBucket.

I think the URL was https://bitbucket.org/openjfxmirrors, but it's 
not valid

anymore.

Is there still a mirror of OpenJFX at BitBucket?

A fork/pull-request workflow is state-of-the-art nowadays in software
development and way better than a patch-file based workflow IMHO.

It would be great to have such a fork/pull-request workflow also for 
OpenJFX!


-Florian

Re: OpenJFX mirror at BitBucket?

[Jonathan Giles]

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 the OpenJDK, and therefore makes 
use of the OpenJDK infrastructure. My main point is that any movement 
regarding infrastructure is guided by an over-arching infrastructure 
team, in conjunction with the OpenJDK masters. OpenJFX can't work 
independent of this.


-- Jonathan

On 18/03/2015 10:50 a.m., Florian Brunner wrote:

Hi,

AFAIK there is/ was a mirror of OpenJFX at BitBucket.

I think the URL was https://bitbucket.org/openjfxmirrors, but it's not valid
anymore.

Is there still a mirror of OpenJFX at BitBucket?

A fork/pull-request workflow is state-of-the-art nowadays in software
development and way better than a patch-file based workflow IMHO.

It would be great to have such a fork/pull-request workflow also for OpenJFX!

-Florian

OpenJFX mirror at BitBucket?

[Florian Brunner]

Hi,

AFAIK there is/ was a mirror of OpenJFX at BitBucket.

I think the URL was https://bitbucket.org/openjfxmirrors, but it's not valid 
anymore.

Is there still a mirror of OpenJFX at BitBucket?

A fork/pull-request workflow is state-of-the-art nowadays in software 
development and way better than a patch-file based workflow IMHO.

It would be great to have such a fork/pull-request workflow also for OpenJFX!

-Florian

[8u60] Review request: RT-39813: [Mac] JavaFX core dumps on Stage#close

[Morris Meyer]

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 - http://cr.openjdk.java.net/~morris/RT-39813.01/
JIRA - https://javafx-jira.kenai.com/browse/RT-39813

Re: libjfxmedia.so on armv6hf?

[Erik De Rijcke]

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 driver also seems to be in the works and a lot of upcoming
arm gpu's seem to be supported as well. By targeting kms/drm you'd be
supporting a lot of platforms with a single codepath now and in the future.

Unrelated, embedded jfx should use
http://wayland.freedesktop.org/libinput/doc/latest/ instead of it's own
bug-risky evdev/raw kernel input implementation. ;)

Now if just somebody would sponser me so I can work fulltime to implement
these things ;)

On Tue, Mar 17, 2015 at 7:39 PM, David Hill  wrote:

> 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 :-)
>
> To start with, an "embedded" application is usually a single purpose
> instead of a general purpose computing device. Think a kiosk for example.
> When I say general purpose devices - I mean classic desktops and now the
> mobile platforms, where the expectation is that the machine will be used
> for a number of application.
>
> Several of you will say that I am wrong, that a Raspberry Pi for example
> behaves just like a pokey "desktop" machine. This is a case where the lines
> have blurred and will continue to get more blurry. The Pi was one of a new
> generation of ARM platforms that have a community around them - a place
> where you can both buy a cheap board and get an OS and drivers without an
> NDA. So just as you can make a kiosk using a desktop machine, you can also
> use the PI with XMBC as a media center.
>
> As part of the "embedded" FX team, our design center was less the Pi
> running with X11, but rather a direct to framebuffer (without the overhead
> and limitations of X11). And the Pi was an after thought for us, a way to
> help out the community. We were targeting a more modern platforms liek the
> i.MX6.
>
> The problem with the direct to framebuffer, and to some extent with the
> rest of the ARM platforms - the platforms are really fractured and it is
> hard to build a working distro. I personally spend many a frustrating day
> trying to get some ARM platform to do something we take for granted on the
> desktop. Starting with OpenGLES drivers, especially ones that would
> talk to the framebuffer (and not X11). The Pi is one of the few examples
> out there of a port that has an easy download that contains most of the
> needed drivers already integrated (and documented). I spent almost a week
> fighting the Beagle Bone Black before getting up. Oh yes - and add on top
> of this all that GL initialization direct to framebuffer is non-standard
> API, so we ended up with 3 code paths for the platforms we were able to
> build.
>
> So in summary it is easy to download a Linux distro. The hardpart is right
> after you do that, and you want the proprietary hardware accelerated
> drivers. There are very few platforms that make this easy.
>
> And the Pi (version 1) is really too slow. The i.MX6 has enough power for
> a real application. The ODROID U3 and XU are also pretty spiffy, but I
> could not get direct to framebuffer working for either of those. If you
> want to use X11 - OpenJFX will probably work for you, and it might even
> have graphical acceleration if the drivers are present and integrated.
>
> Our Embedded team had ARM media as the next big thing to do, but ...
>
> So now we have all of the gstreamer code in the OpenJFX repo. I really
> expect that media on the Pi (1) will probably not work well due to the
> speed of the CPU and the memory bus. Maybe the Pi 2.
>
> Again, you really need the right drivers in place to take advantage of
> hardware accelerated decoding of the media stream.
>
> With the right gstreamer libraries and drivers, I expect the media port
> would not take that long for someone that understands gstreamer.
>
> There might need to be some changes in Monocle to take the video stream
> hand off.
>
> I really would not expect that media would work without some debugging,
> and that after getting the build issues worked out.
>
>
>
>
>> 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 workaround, can't openjfx simply be compiled on an arm host
>> (so no cross compilation is required) and as such generate the missing
>> libraries? Qemu with an arm vm can be used to do that on an x86 host for
>> example.
>>
>> On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici<
>> fabrizio.giud...@tidalwave.it>  wrote:
>>
>>  O

Re: libjfxmedia.so on armv6hf?

[ngalarneau]

Thank you, David, for explaining all that is involved to us desktop-types. 
:-)


Neil




From:   David Hill 
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 :-)

To start with, an "embedded" application is usually a single purpose 
instead of a general purpose computing device. Think a kiosk for example. 
When I say general purpose devices - I mean classic desktops and now the 
mobile platforms, where the expectation is that the machine will be used 
for a number of application.

Several of you will say that I am wrong, that a Raspberry Pi for example 
behaves just like a pokey "desktop" machine. This is a case where the 
lines have blurred and will continue to get more blurry. The Pi was one of 
a new generation of ARM platforms that have a community around them - a 
place where you can both buy a cheap board and get an OS and drivers 
without an NDA. So just as you can make a kiosk using a desktop machine, 
you can also use the PI with XMBC as a media center.

As part of the "embedded" FX team, our design center was less the Pi 
running with X11, but rather a direct to framebuffer (without the overhead 
and limitations of X11). And the Pi was an after thought for us, a way to 
help out the community. We were targeting a more modern platforms liek the 
i.MX6.

The problem with the direct to framebuffer, and to some extent with the 
rest of the ARM platforms - the platforms are really fractured and it is 
hard to build a working distro. I personally spend many a frustrating day 
trying to get some ARM platform to do something we take for granted on the 
desktop. Starting with OpenGLES drivers, especially ones that would 
talk to the framebuffer (and not X11). The Pi is one of the few examples 
out there of a port that has an easy download that contains most of the 
needed drivers already integrated (and documented). I spent almost a week 
fighting the Beagle Bone Black before getting up. Oh yes - and add on top 
of this all that GL initialization direct to framebuffer is non-standard 
API, so we ended up with 3 code paths for the platforms we were able to 
build.

So in summary it is easy to download a Linux distro. The hardpart is right 
after you do that, and you want the proprietary hardware accelerated 
drivers. There are very few platforms that make this easy.

And the Pi (version 1) is really too slow. The i.MX6 has enough power for 
a real application. The ODROID U3 and XU are also pretty spiffy, but I 
could not get direct to framebuffer working for either of those. If you 
want to use X11 - OpenJFX will probably work for you, and it might even 
have graphical acceleration if the drivers are present and integrated.

Our Embedded team had ARM media as the next big thing to do, but ...

So now we have all of the gstreamer code in the OpenJFX repo. I really 
expect that media on the Pi (1) will probably not work well due to the 
speed of the CPU and the memory bus. Maybe the Pi 2.

Again, you really need the right drivers in place to take advantage of 
hardware accelerated decoding of the media stream.

With the right gstreamer libraries and drivers, I expect the media port 
would not take that long for someone that understands gstreamer.

There might need to be some changes in Monocle to take the video stream 
hand off.

I really would not expect that media would work without some debugging, 
and that after getting the build issues worked out.


>
> 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 workaround, can't openjfx simply be compiled on an arm host
> (so no cross compilation is required) and as such generate the missing
> libraries? Qemu with an arm vm can be used to do that on an x86 host for
> example.
>
> On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici<
> fabrizio.giud...@tidalwave.it>  wrote:
>
>> On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick<
>> felix.bembr...@gmail.com>  wrote:
>>
>>   I really admire guys like this and wish that my own personal 
circumstances
>>> enabled me to get involved in a similar way but my main concern is 
that
>>> the
>>> "community" required to make JavaFX truly viable on iOS, Android and 
ARM
>>> needs to be about 50-100 times bigger than it currently is.  Without 
an
>>>
>> It's my concern too. At this point we're at 20 years of Java, and I 
lived
>> them from the very beginning. The idea "the community will fix it" is a
>> déjà vu that, unfortunately, says that in the past the thing didn't 
work
>> many 

Re: libjfxmedia.so on armv6hf?

[David Hill]

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 :-)

To start with, an "embedded" application is usually a single purpose instead of 
a general purpose computing device. Think a kiosk for example. When I say general purpose 
devices - I mean classic desktops and now the mobile platforms, where the expectation is 
that the machine will be used for a number of application.

Several of you will say that I am wrong, that a Raspberry Pi for example behaves just 
like a pokey "desktop" machine. This is a case where the lines have blurred and 
will continue to get more blurry. The Pi was one of a new generation of ARM platforms 
that have a community around them - a place where you can both buy a cheap board and get 
an OS and drivers without an NDA. So just as you can make a kiosk using a desktop 
machine, you can also use the PI with XMBC as a media center.

As part of the "embedded" FX team, our design center was less the Pi running 
with X11, but rather a direct to framebuffer (without the overhead and limitations of 
X11). And the Pi was an after thought for us, a way to help out the community. We were 
targeting a more modern platforms liek the i.MX6.

The problem with the direct to framebuffer, and to some extent with the rest of 
the ARM platforms - the platforms are really fractured and it is hard to build 
a working distro. I personally spend many a frustrating day trying to get some 
ARM platform to do something we take for granted on the desktop. Starting 
with OpenGLES drivers, especially ones that would talk to the framebuffer 
(and not X11). The Pi is one of the few examples out there of a port that has 
an easy download that contains most of the needed drivers already integrated 
(and documented). I spent almost a week fighting the Beagle Bone Black before 
getting up. Oh yes - and add on top of this all that GL initialization direct 
to framebuffer is non-standard API, so we ended up with 3 code paths for the 
platforms we were able to build.

So in summary it is easy to download a Linux distro. The hardpart is right 
after you do that, and you want the proprietary hardware accelerated drivers. 
There are very few platforms that make this easy.

And the Pi (version 1) is really too slow. The i.MX6 has enough power for a 
real application. The ODROID U3 and XU are also pretty spiffy, but I could not 
get direct to framebuffer working for either of those. If you want to use X11 - 
OpenJFX will probably work for you, and it might even have graphical 
acceleration if the drivers are present and integrated.

Our Embedded team had ARM media as the next big thing to do, but ...

So now we have all of the gstreamer code in the OpenJFX repo. I really expect 
that media on the Pi (1) will probably not work well due to the speed of the 
CPU and the memory bus. Maybe the Pi 2.

Again, you really need the right drivers in place to take advantage of hardware 
accelerated decoding of the media stream.

With the right gstreamer libraries and drivers, I expect the media port would 
not take that long for someone that understands gstreamer.

There might need to be some changes in Monocle to take the video stream hand 
off.

I really would not expect that media would work without some debugging, and 
that after getting the build issues worked out.




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 workaround, can't openjfx simply be compiled on an arm host
(so no cross compilation is required) and as such generate the missing
libraries? Qemu with an arm vm can be used to do that on an x86 host for
example.

On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici<
fabrizio.giud...@tidalwave.it>  wrote:


On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick<
felix.bembr...@gmail.com>  wrote:

  I really admire guys like this and wish that my own personal circumstances

enabled me to get involved in a similar way but my main concern is that
the
"community" required to make JavaFX truly viable on iOS, Android and ARM
needs to be about 50-100 times bigger than it currently is.  Without an


It's my concern too. At this point we're at 20 years of Java, and I lived
them from the very beginning. The idea "the community will fix it" is a
déjà vu that, unfortunately, says that in the past the thing didn't work
many times.

This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2
arrives, I'll try the option you and others suggested.


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it




--
David Hill
Java Embedded Developmen

Re: libjfxmedia.so on armv6hf?

[Chris Newland]

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, Kevin Rushforth wrote:
> 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 there IP /
>> licensing issues here?
>>
>> I understand that a decision was made to reassign resources but I think
>>  there's enough brainpower out here in userland to finish the job if
>> all the sources were made available.
>>
>> Thanks,
>>
>>
>> Chris
>> @chriswhocodes
>>
>>
>> On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:
>>
>>
>>> Media and web have not ever been supported or delivered on linux-arm.
>>>
>>>
>>>
>>> Seems that libjfxmedia.so should be excluded by the openZips target.
>>> David can response further.
>>>
>>>
>>>
>>> -- Kevin
>>>
>>>
>>>
>>>
>>> Chris Newland wrote:
>>>
>>>
>>>
 In reference to
 http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=72026
 7#p7
 20267



 When cross-compiling to armv6hf on an x86-64 Linux system using:



 gradle clean openZip -PCOMPILE_TARGETS=armv6hf

 Some of the binaries are compiled as x86-64:



 file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

 build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared
 object, x86-64, version 1 (SYSV), dynamically linked,
 BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not
 stripped


 Is this a simple gradle error or is it not currently possible to
 build some of the JavaFX libraries for ARM?

 Thanks,



 Chris






>>
>>
>>
>

Re: libjfxmedia.so on armv6hf?

[Kevin Rushforth]

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 there IP / licensing
issues here?

I understand that a decision was made to reassign resources but I think
there's enough brainpower out here in userland to finish the job if all
the sources were made available.

Thanks,

Chris
@chriswhocodes

On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:
  

Media and web have not ever been supported or delivered on linux-arm.


Seems that libjfxmedia.so should be excluded by the openZips target.
David can response further.


-- Kevin



Chris Newland wrote:



In reference to
http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=720267#p7
20267


When cross-compiling to armv6hf on an x86-64 Linux system using:


gradle clean openZip -PCOMPILE_TARGETS=armv6hf

Some of the binaries are compiled as x86-64:


file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared
object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped


Is this a simple gradle error or is it not currently possible to build
some of the JavaFX libraries for ARM?

Thanks,


Chris




  



  

Re: libjfxmedia.so on armv6hf?

[Erik De Rijcke]

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 workaround, can't openjfx simply be compiled on an arm host
(so no cross compilation is required) and as such generate the missing
libraries? Qemu with an arm vm can be used to do that on an x86 host for
example.

On Tue, Mar 17, 2015 at 12:50 PM, Fabrizio Giudici <
fabrizio.giud...@tidalwave.it> wrote:

> On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick <
> felix.bembr...@gmail.com> wrote:
>
>  I really admire guys like this and wish that my own personal circumstances
>> enabled me to get involved in a similar way but my main concern is that
>> the
>> "community" required to make JavaFX truly viable on iOS, Android and ARM
>> needs to be about 50-100 times bigger than it currently is.  Without an
>>
>
> It's my concern too. At this point we're at 20 years of Java, and I lived
> them from the very beginning. The idea "the community will fix it" is a
> déjà vu that, unfortunately, says that in the past the thing didn't work
> many times.
>
> This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2
> arrives, I'll try the option you and others suggested.
>
>
> --
> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
> "We make Java work. Everywhere."
> http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
>

Re: libjfxmedia.so on armv6hf?

[Fabrizio Giudici]

On Tue, 17 Mar 2015 01:21:29 +0100, Felix Bembrick  
 wrote:


I really admire guys like this and wish that my own personal  
circumstances
enabled me to get involved in a similar way but my main concern is that  
the

"community" required to make JavaFX truly viable on iOS, Android and ARM
needs to be about 50-100 times bigger than it currently is.  Without an


It's my concern too. At this point we're at 20 years of Java, and I lived  
them from the very beginning. The idea "the community will fix it" is a  
déjà vu that, unfortunately, says that in the past the thing didn't work  
many times.


This doesn't mean I'm necessarily in a fatalistic mood. When my RPI2  
arrives, I'll try the option you and others suggested.


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it