javafxpackager and launcher wrappers now in OpenJFX 8

[Artem Ananiev]

Hi, Daniel,

On 12/21/2012 4:36 PM, Daniel Zwolenski wrote:
> 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?

this is a problem in rt/deploy sources. afxres.h is a header from VC, 
not Windows SDK, it's shipped with VC Professional and missed in VC Express.

Fortunately, the fix is easy: just replace #include "afxres.h" with 
#include <windows.h> in javafxpackager.rc

If you then face another failure when building IconSwap.vcxproj, please, 
let me know. I had a problem with this project file, but not sure if 
it's an issue with my environment.

Thanks,

Artem

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