javafx-font opensourced

[Daniel Zwolenski]

Are we talking Oracle or OpenJDK here. I got the impression those libs were
Open?

I think it's much better that this is built into the OpenJFX/JDK automated
build scripts and you guys execute them. Most of us in the community do not
have the infrastructure to do cross platform builds of all this and you
guys do (and you are running those builds regularly anyway).

We would end up with one person building the Mac release, another person
doing the win one. And this would need to happen for every snapshot - and
what if they accidentally check out the wrong code, etc. Confusion and
chaos - and if I was a malicious entity I could easily upload a snapshot
that deleted everyone's hard drive. You wouldn't be responsible, but you
sure wouldn't be winning too much good publicity.

All it usually involves is an extra command added at the end of your build.
A 'deploy' command will automatically publish a snapshot release when run.
Instant and done. Official 'release' takes a couple more steps but still
probably adds about 30seconds to a minute on your normal release which
happens once or twice a year.

Since you are using a Gradle build, I assume you can just easily integrate
this:
http://www.gradle.org/docs/current/javadoc/org/gradle/api/artifacts/maven/MavenDeployer.html

If you want the community to help you guys setup your build to do this,
that's a fair enough request, but I don't see any reason why anyone would
want to double up on all the build work you guys do anyway, with the risk
of all the things that could go wrong, when it's minimal extra effort for
you guys to just add a deploy line to your existing scripts.




On Fri, Jun 21, 2013 at 4:51 PM, Richard Bair <richard.bair at oracle.com>wrote:

> Oracle has this thing about wanting to self host everything. However that
> doesn't stop the community from putting OpenJDK / OpenJFX stuff somewhere
> reasonable until Oracle finally gets all the infrastructure in place and
> the OpenJDK project can then take advantage of it.
>
> Richard
>
> On Jun 20, 2013, at 11:34 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
>
> Why not use Sonatype for your repo?
>
> For third party jars that aren't in central, you can upload these assuming
> the licence allows it:
>
> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
>
> For your own stuff that you aren't going to publish for real but still
> want to be available (e.g. latest releases of JFX), publish it as a
> SNAPSHOT. For real stuff, publish it proper into the Maven repo and make it
> available for use by the community.
>
> It certainly would make my life massively more enjoyable if a build of the
> JRE was available for download for each of the platforms. And things like
> win-launcher.exe and other secondary assets would also make it much easier
> to work on the packaging tools, etc.
>
>
>
> On Fri, Jun 21, 2013 at 2:34 PM, Richard Bair <richard.bair at oracle.com>wrote:
>
>> Yes, working on the web view building. The main issue is there are a
>> handful of libs (libxml, libxslt, etc) that we have to figure out where to
>> put. I believe these are unaltered by us, but built with different flags to
>> strip out stuff we don't need. I've asked Peter whether we can post the
>> build instructions to produce these libs, and then figured once anyone can
>> build them, it wouldn't be to hard to find a place to put them.
>>
>> Ultimately we're trying to get a public artifactory repository setup for
>> OpenJDK which would be the natural place for us to put all our dependencies
>> like this, but in the meantime we just need a place to put some binaries. I
>> know some of these binaries could be found elsewhere but not all of them
>> (win64 builds I think are missing for example).
>>
>> On Jun 20, 2013, at 8:56 PM, Danno Ferrin <danno.ferrin at shemnon.com>
>> wrote:
>>
>> > On Thu, Jun 20, 2013 at 5:21 PM, Daniel Zwolenski <zonski at gmail.com>
>> wrote:
>> >
>> >> This time sending to the list (gets me every time!):
>> >>
>> >> Great news!
>> >>
>> >> Danno - where does this put us with the JFX78 backport? Can we get a
>> build
>> >> of this for iOS now or what's needed to close this loop?
>> >>
>> >>
>> > The good news is that my JFX78 project now compiles via gradle without
>> > needing a stub jar.  I took out the date picker and the builders for
>> media
>> > and web view.  So you can download it locally and build a jfxrt.jar and
>> > likely use the ios libs that build currently.  I haven't poked around
>> too
>> > much with the native bits.  (see https://bitbucket.org/narya/jfx78)
>> >
>> > I also have been working on some maven distribution for this, not ready
>> > for consumption yet but an accessory build file creates the poms and
>> > handles the upload tasks (
>> >
>> https://bitbucket.org/narya/jfx78/src/3fe6c37ebdfbed33d1bdc9ad9d6a2037972de680/narya.gradle?at=default
>> > ).
>> >
>> > The date picker will return when the threetenbp jars are updated, and
>> media
>> > when those files are released.  WebView I either need to submit a patch
>> to
>> > get it building in gradle or be patient.  But honestly all three of
>> these
>> > rank in priority for me below writing a jfpackager bundler that wraps
>> > robovm.
>> >
>> >
>> > The RoboVM Maven plugin is working. I'd be keen to make it work with JFX
>> >> auto included so basically you can create a normal project and run mvn
>> >> robovm:ipad-simulator (robovm:ios-device is under construction) and
>> next
>> >> thing you have a running JFX app on iOS, no mess, no fuss.
>> >>
>> >> I have a pitch for a suite of fairly major app development next week.
>> So
>> >> many unknowns with JFX and app development at this stage! I'm still
>> pretty
>> >> disappointed that JFX on iOS/Android is not officially supported by
>> Oracle
>> >> (such a massive wtf? for me) - makes it such a risky prospect for us
>> on the
>> >> front line.
>> >>
>> >>
>> >> On Fri, Jun 21, 2013 at 3:47 AM, Felipe Heidrich <
>> >> felipe.heidrich at oracle.com
>> >>> wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>>
>> >>> We have just open-sourced javafx-font and javafx-font-native!
>> >>>
>> >>> Note that a lot of the code we open-sourced today is a new
>> implementation
>> >>> based on native text technologies (CoreText for the Mac and
>> DirectWrite
>> >> for
>> >>> Windows).
>> >>>
>> >>> We still have a lot of work to do:
>> >>> - finishing the new linux implementation is a big one
>> >>> - testing
>> >>> - improve on sub pixel position text
>> >>> - etc
>> >>>
>> >>> Help is most welcome,
>> >>>
>> >>> Thank you
>> >>> Felipe
>> >>>
>> >>>
>> >>
>>
>>
>
>