javafxpackager and launcher wrappers now in OpenJFX 8
Daniel Zwolenski
zonski at gmail.com
Tue Dec 25 14:27:13 PST 2012
Thanks Artem!
I just tried it with the change and it seems to be getting further.
I think I need to set up some properties somewhere though; a bunch of
things seem to be referencing various variables that aren't set. I could
try manually setting each one that fails, but if you guys could share a
copy of the properties file that you use (or talk me through it, or
whatever), I'd feel more confident that I'm not missing anything. Since
I'll basically be doing the build that gets released it would be great if
it could be as close to the official build as possible.
Here's some of the error log that looks most relevant:
winlaunch:
Property "jfx.release.major.version" has not been set
Property "jfx.release.minor.version" has not been set
Property "jfx.release.micro.version" has not been set
[copy]
C:\dev\openjfx\8\master\rt\deploy\packager\winlauncher\javafxpackager.manifest
omitted as
C:\dev\openjfx\8\master\rt\deploy\packager\winlauncher\build\javafxpackager.manifest
is up to date.
[exec] Current OS is Windows 7
[exec] Output redirected to property: cygwin.path
[exec] Executing 'cygpath' with arguments:
[exec] '-m'
[exec] '-s'
[exec] '/'
[exec]
[exec] The ' characters around the executable and arguments are
[exec] not part of the command.
[available] Unable to find file C:\apps\cygwin\bin\g++-3.exe
[property] Loading C:\dev\openjfx\8\master\rt\deploy\vs.properties
Property "jfx.release.major.version" has not been set
Property "jfx.release.minor.version" has not been set
Property "jfx.release.micro.version" has not been set
Property "short.platform.home" has not been set
Property "winlauncher.class.dir" has not been set
[exec] Current OS is Windows 7
[exec] Setting environment variable:
FX_MAJOR_VERSION=${jfx.release.major.version}
[exec] Setting environment variable:
FX_MINOR_VERSION=${jfx.release.minor.version}
[exec] Setting environment variable:
FX_UPDATE_VERSION=${jfx.release.micro.version}
[exec] Setting environment variable: FX_BUILD_NUMBER=0000
...
[exec] Setting environment variable: JDK_HOME=${short.platform.home}
[exec] Setting environment variable: CONF=Release
[exec] Setting environment variable: DIST_DIR=dist
[exec] Setting environment variable: BUILD_DIR=build
[exec] Setting environment variable: CLASS_DIR=${winlauncher.class.dir}
[exec] Executing 'C:\WINDOWS\System32\cmd.exe' with arguments:
[exec] '/C'
[exec] 'C:\apps\cygwin\bin\make.exe'
[exec] '-f'
[exec] 'Makefile'
[exec] ''
[exec]
[exec] The ' characters around the executable and arguments are
[exec] not part of the command.
[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]
[exec] javafxpackager.rc(20) : error RC2127 : version WORDs separated
by commas expected
[exec] Makefile:77: recipe for target `dist/javafxpackager.exe' failed
[exec] make: *** [dist/javafxpackager.exe] Error 2
[ant] Exiting C:\dev\openjfx\8\master\rt\deploy\packager\build.xml.
On Tue, Dec 25, 2012 at 11:15 PM, Artem Ananiev <artem.ananiev at oracle.com>wrote:
>
> Here is the bug filed about this build failure:
>
> http://javafx-jira.kenai.com/**browse/RT-27209<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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
More information about the openjfx-dev
mailing list