javafxpackager and launcher wrappers now in OpenJFX 8

[Daniel Zwolenski]

I've had a crack at trying to build this. Got part of the way but hit some
problems now. Is there any docco on how to do this or is it just muddle
through it?

I worked out the whole clone master and then clone rt thing. Then I
installed Cygwin and eventually got that working. I already had Visual
Studio (10) installed and looks like it found it but I didn't do anything
to make it work.

I got an error relating to a file with ${jfx.build.dir} in the path so I
added this property in a random properties file (project.properties) to be
".".  I imagine that's not right but it got me further.

It gives a bunch of warnings about propriety APIs in -do-compile but seems
to get passed this bit.

I see the following message a fair bit, but not sure it's a problem?

    [taskdef] Could not load definitions from resource
net/sf/antcontrib/antcontrib.properties. It could not be found.

Eventually the build fails with this error though:

winlaunch:
     [copy] Copying 1 file to
C:\dev\openjfx\8\master\rt\deploy\packager\winlauncher\build
     [exec] cl.exe -nologo -MT -Fdbuild/ -GS -W3 -EHsc -DWIN32
 -D_LITTLE_ENDIAN -DWIN32_LEAN_AND_MEAN  -D_WIN32_WINDOWS=0x0500
-D_WIN32_WINNT=0x0500 -I.  -Ibuild -I/include  -I/include/win32 -I/Include
-c -Zi -O2 -Fobuild/main.obj main.cpp
     [exec] main.cpp
     [exec] main.cpp(259) : warning C4018: '<' : signed/unsigned mismatch
     [exec] main.cpp(270) : warning C4018: '<' : signed/unsigned mismatch
     [exec] main.cpp(287) : warning C4018: '<' : signed/unsigned mismatch
     [exec] main.cpp(427) : warning C4996: 'getenv': This function or
variable may be unsafe. Consider using _dupenv_s instead. To disable
deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
     [exec]         c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\stdlib.h(433) : see declaration of 'getenv'
     [exec] rc.exe /l 0x409 /r /Ibuild -d "JFX_DVERSION=...0000"  -d
"JFX_VERSION=,,,0000" -d NDEBUG -fobuild/javafxpackager.res
javafxpackager.rc
     [exec] Microsoft (R) Windows (R) Resource Compiler Version
6.1.7600.16385
     [exec] Copyright (C) Microsoft Corporation.  All rights reserved.
     [exec]
     [exec] javafxpackager.rc(6) : fatal error RC1015: cannot open include
file 'afxres.h'.
     [exec] Makefile:77: recipe for target `dist/javafxpackager.exe' failed
     [exec] make: *** [dist/javafxpackager.exe] Error 1

BUILD FAILED
C:\dev\openjfx\8\master\rt\deploy\build.xml:84: The following error
occurred while executing this line:
C:\dev\openjfx\8\master\rt\deploy\packager\build.xml:290: exec returned: 2


Any tips on what to do next?

By the way, my first goal with this is to be able to build all this stuff
and then I intend to upload it to the central Maven repo so everyone using
Ivy, Maven, Grails, etc, can use these libraries in their own
tools/plugins/etc. If you're not familiar with Maven, uploading it to
central is basically like putting it on a big FTP server that anyone can
download it from. All the other OSS projects are up there from apache
commons, to Spring, to whatever you want. You don't have to build the code
using Maven to do this, this deployment is a separate process.

Typically this sort of distribution would be managed by the vendor but I'm
assuming you guys aren't interested in doing that?

The Sonatype guys (who we upload via) won't care if it is you or me (since
your licence gives me the right) but it will be deployed under the "javafx"
(or "javafx.deploy") groupId. So they will give me access to this, which
means I could deploy anything I want (e.g. something malicious) and it
would, to an outsider, look reasonably like an official Oracle release.
Anyone referencing that JAR (e.g. the Gradle plugin or maybe an IDE like
Eclipse or IntelliJ) would then end up with my malicious bit of code. Not
your problem officially but not the best situation to find yourselves in.

Now obviously I'm not going to do that, and anything I do is easily traced
back to me for beatings, but if it were me in your shoes I'd be inclined to
keep control over that sort of thing for something as big and widely used
as Maven. Up to you how you want to move forward. I would be very happy to
work with you guys, do 90% of the leg work and help you sort this out if
you want. If not I'd also be fine to just get it into the repo myself (and
in the absence of a clear decision from you guys that's what I'll do). I'm
wanting to move pretty fast on this though, so looking for something that
will happen over the next few weeks rather than months.

Cheers,
Dan







On Thu, Dec 20, 2012 at 10:57 AM, Kevin Rushforth <
kevin.rushforth at oracle.com> wrote:

> Slight correction. They are in the 8/controls/rt repo now, and will be in
> the 8/master/rt repo after Thursday's promoted build.
>
> -- Kevin
>
>
>
> Scott Kovatch wrote:
>
>> Hello,
>>
>> The packager and launcher wrapper classes are now in the master OpenJFX 8
>> repository, in rt/deploy. It's not wired up to the top-level build.xml yet,
>> and it looks like I have some dependencies on build variables in the closed
>> JavaFX build. Everything compiles, and the output ends up in rt/deploy/dist.
>>
>> But, you should be able to get the source and start looking at how
>> bundled apps are produced, and see what goes into dtjava.js. As time
>> permits I'll try to clean up the output locations so everything ends up in
>> artifacts.
>>
>> -- Scott K.
>>
>> --
>> Scott Kovatch
>> scott.kovatch at oracle.com
>> Pleasanton, CA
>>
>>
>>
>>
>>
>