javafxpackager and launcher wrappers now in OpenJFX 8

[Artem Ananiev]

Here is the bug filed about this build failure:

http://javafx-jira.kenai.com/browse/RT-27209

Thanks,

Artem

On 12/25/2012 4:10 PM, Artem Ananiev wrote:
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>