[10] Review request: 8194040: "javapackager -help" doesn't display new option "-singleton"
Kevin, Please review my changes for fixing the issue: "8194040: "javapackager -help" doesn't display new option "-singleton"" JIRA: https://bugs.openjdk.java.net/browse/JDK-8194040 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8194040/webrev.00/ --Victor
[10] Review request: 8188314: Fix typos in FX API docs
I'm sending this review on behalf of Jon Gibbons who provided the fix for these javadoc errors: https://bugs.openjdk.java.net/browse/JDK-8188314 http://cr.openjdk.java.net/~jjg/8188314/webrev.00/ -- Kevin
[8u] Review request: 8178275: Ensemble: Upgrade version of Lucene to 7.1.0
Hi Phil, I request a review to backport JDK-8178275 to 8u-dev. The backport was straight-forward. https://bugs.openjdk.java.net/browse/JDK-8178275 http://cr.openjdk.java.net/~kcr/8178275/8u/webrev.00/ Thanks. -- Kevin
Re: Windows Build setupTools
One of the reasons I would like to eliminate Cygwin is that I believe it causes more problems than it is worth. For example, lat time I check, there was a bunch of code in the build scripts to hack paths because Cygwin apparently wants non-Windows paths on Windows. It’s the “let’s pretend we aren’t on Windows and make a mess” strategy employed by Cygwin that I find counter-productive. (As a developer, I do like having common Un*x tools installed, but I prefer Windows ports of those tools that understand how to properly run on Windows instead of creating some virtual unix environment that doesn’t quite fit.) I suspect a lot more build logic could be done within the Gradle scripts rather than using external tools. That would result in a more portable build experience with less places for things to go wrong. Regards, Scott > On Dec 21, 2017, at 12:14 PM, jav...@use.startmail.com wrote: > > I did not try Tom's build instructions however I can contribute that having > Cygwin on Windows 7 and following the build instructions as posted on the > JavaFX build instructions page is not suffcient to result in a successful > build. > > The exact error messages I was receiving I posted earlier . > > > On Thursday, December 21, 2017 3:08 AM, Michael Ennen > wrote: > >> Thanks for the tip, Tom. I understand that Cygwin is a dependency of >> building on Windows but didn't >> know that the properties are only configured on a cygwin shell. >> I have a pseudo-goal of removing the Cygwin dependency from building >> OpenJFX on Windows and >> I wonder why Cygwin is necessary for setupTools to work? I see other >> obvious places in the build >> files that would only work on Cygwin, but am unclear as to why the >> properties would not be set >> in cmd.exe or Powershell. >> Thanks again for the clarification. >> On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl >> wrote: >> >>> Hi Michael, >>> I did not had to setup any special variables and documented my steps at >>> https://github.com/BestSolution-at/openjfx-build. >>> I had trouble myself initially but the reason was that I ran the "gradle >>> sdk" command from within a MSDOS-Shell but you really need to run it within >>> cygwin. >>> Tom >>> On 21.12.17 06:40, Michael Ennen wrote: >>> Some people were reporting that Windows builds are difficult to setup. I think this is due to the fact that the call to setupTools in buildSrc/win.gradle is in fact not working correctly. Invoking buildSrc/genVSproperties.bat directly prints the correct properties. However adding some debugging to setupTools it is clear that something is very wrong with it. This is the result: WINDOWS_VS_DEVENVDIR= WINDOWS_VS_DEVENVCMD=/VCExpress.exe WINDOWS_VS_VCINSTALLDIR= WINDOWS_VS_VSINSTALLDIR= WINDOWS_VS_MSVCDIR= WINDOWS_VS_INCLUDE= WINDOWS_VS_LIB= WINDOWS_VS_LIBPATH= WINDOWS_VS_PATH=; WINDOWS_VS_VER=120 WINDOWS_SDK_DIR= WINDOWS_SDK_VERSION= This is the reason people are needing to hard-code values for the properties below the call to setupTools. I am trying to debug what is actually wrong with setupTools but so far not making much progress. I tried this on my local Windows 10 machine and Appveyor VMs and the result is the same. I also read at least two mails in this list about needing to hard-code the properties, I am assuming it is for the same reason. I will try and figure out the reason but wanted to at least make this issue more concrete. >> -- >> Michael Ennen
Re: Windows Build setupTools
I did not try Tom's build instructions however I can contribute that having Cygwin on Windows 7 and following the build instructions as posted on the JavaFX build instructions page is not suffcient to result in a successful build. The exact error messages I was receiving I posted earlier . On Thursday, December 21, 2017 3:08 AM, Michael Ennen wrote: Thanks for the tip, Tom. I understand that Cygwin is a dependency of building on Windows but didn't know that the properties are only configured on a cygwin shell. I have a pseudo-goal of removing the Cygwin dependency from building OpenJFX on Windows and I wonder why Cygwin is necessary for setupTools to work? I see other obvious places in the build files that would only work on Cygwin, but am unclear as to why the properties would not be set in cmd.exe or Powershell. Thanks again for the clarification. On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl wrote: Hi Michael, I did not had to setup any special variables and documented my steps at https://github.com/BestSolution-at/openjfx-build. I had trouble myself initially but the reason was that I ran the "gradle sdk" command from within a MSDOS-Shell but you really need to run it within cygwin. Tom On 21.12.17 06:40, Michael Ennen wrote: Some people were reporting that Windows builds are difficult to setup. I think this is due to the fact that the call to setupTools in buildSrc/win.gradle is in fact not working correctly. Invoking buildSrc/genVSproperties.bat directly prints the correct properties. However adding some debugging to setupTools it is clear that something is very wrong with it. This is the result: WINDOWS_VS_DEVENVDIR= WINDOWS_VS_DEVENVCMD=/VCExpress.exe WINDOWS_VS_VCINSTALLDIR= WINDOWS_VS_VSINSTALLDIR= WINDOWS_VS_MSVCDIR= WINDOWS_VS_INCLUDE= WINDOWS_VS_LIB= WINDOWS_VS_LIBPATH= WINDOWS_VS_PATH=; WINDOWS_VS_VER=120 WINDOWS_SDK_DIR= WINDOWS_SDK_VERSION= This is the reason people are needing to hard-code values for the properties below the call to setupTools. I am trying to debug what is actually wrong with setupTools but so far not making much progress. I tried this on my local Windows 10 machine and Appveyor VMs and the result is the same. I also read at least two mails in this list about needing to hard-code the properties, I am assuming it is for the same reason. I will try and figure out the reason but wanted to at least make this issue more concrete. -- Michael Ennen
Re: Windows Build setupTools
Ah I see now - the properties were not being re-generated simply because the file windows_tools.properties already existed and "gradle clean" was not working because I'm not on Cygwin. Sorry for the noise. On Thu, Dec 21, 2017 at 1:08 AM, Michael Ennen wrote: > Thanks for the tip, Tom. I understand that Cygwin is a dependency of > building on Windows but didn't > know that the properties are only configured on a cygwin shell. > > I have a pseudo-goal of removing the Cygwin dependency from building > OpenJFX on Windows and > I wonder why Cygwin is necessary for setupTools to work? I see other > obvious places in the build > files that would only work on Cygwin, but am unclear as to why the > properties would not be set > in cmd.exe or Powershell. > > Thanks again for the clarification. > > On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl > wrote: > >> Hi Michael, >> >> I did not had to setup any special variables and documented my steps at >> https://github.com/BestSolution-at/openjfx-build. >> >> I had trouble myself initially but the reason was that I ran the "gradle >> sdk" command from within a MSDOS-Shell but you really need to run it within >> cygwin. >> >> Tom >> >> >> On 21.12.17 06:40, Michael Ennen wrote: >> >>> Some people were reporting that Windows builds are difficult to setup. >>> I think this is due to the fact that the call to setupTools in >>> buildSrc/win.gradle >>> is in fact not working correctly. >>> >>> Invoking buildSrc/genVSproperties.bat directly prints the correct >>> properties. >>> >>> However adding some debugging to setupTools it is clear that something is >>> very wrong >>> with it. This is the result: >>> >>> WINDOWS_VS_DEVENVDIR= >>> WINDOWS_VS_DEVENVCMD=/VCExpress.exe >>> WINDOWS_VS_VCINSTALLDIR= >>> WINDOWS_VS_VSINSTALLDIR= >>> WINDOWS_VS_MSVCDIR= >>> WINDOWS_VS_INCLUDE= >>> WINDOWS_VS_LIB= >>> WINDOWS_VS_LIBPATH= >>> WINDOWS_VS_PATH=; >>> WINDOWS_VS_VER=120 >>> WINDOWS_SDK_DIR= >>> WINDOWS_SDK_VERSION= >>> >>> This is the reason people are needing to hard-code values for the >>> properties >>> below the call to setupTools. >>> >>> I am trying to debug what is actually wrong with setupTools but so far >>> not >>> making much >>> progress. I tried this on my local Windows 10 machine and Appveyor VMs >>> and >>> the result >>> is the same. I also read at least two mails in this list about needing to >>> hard-code the >>> properties, I am assuming it is for the same reason. >>> >>> I will try and figure out the reason but wanted to at least make this >>> issue >>> more concrete. >>> >>> > > > -- > Michael Ennen > -- Michael Ennen
Re: Windows Build setupTools
Thanks for the tip, Tom. I understand that Cygwin is a dependency of building on Windows but didn't know that the properties are only configured on a cygwin shell. I have a pseudo-goal of removing the Cygwin dependency from building OpenJFX on Windows and I wonder why Cygwin is necessary for setupTools to work? I see other obvious places in the build files that would only work on Cygwin, but am unclear as to why the properties would not be set in cmd.exe or Powershell. Thanks again for the clarification. On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl wrote: > Hi Michael, > > I did not had to setup any special variables and documented my steps at > https://github.com/BestSolution-at/openjfx-build. > > I had trouble myself initially but the reason was that I ran the "gradle > sdk" command from within a MSDOS-Shell but you really need to run it within > cygwin. > > Tom > > > On 21.12.17 06:40, Michael Ennen wrote: > >> Some people were reporting that Windows builds are difficult to setup. >> I think this is due to the fact that the call to setupTools in >> buildSrc/win.gradle >> is in fact not working correctly. >> >> Invoking buildSrc/genVSproperties.bat directly prints the correct >> properties. >> >> However adding some debugging to setupTools it is clear that something is >> very wrong >> with it. This is the result: >> >> WINDOWS_VS_DEVENVDIR= >> WINDOWS_VS_DEVENVCMD=/VCExpress.exe >> WINDOWS_VS_VCINSTALLDIR= >> WINDOWS_VS_VSINSTALLDIR= >> WINDOWS_VS_MSVCDIR= >> WINDOWS_VS_INCLUDE= >> WINDOWS_VS_LIB= >> WINDOWS_VS_LIBPATH= >> WINDOWS_VS_PATH=; >> WINDOWS_VS_VER=120 >> WINDOWS_SDK_DIR= >> WINDOWS_SDK_VERSION= >> >> This is the reason people are needing to hard-code values for the >> properties >> below the call to setupTools. >> >> I am trying to debug what is actually wrong with setupTools but so far not >> making much >> progress. I tried this on my local Windows 10 machine and Appveyor VMs and >> the result >> is the same. I also read at least two mails in this list about needing to >> hard-code the >> properties, I am assuming it is for the same reason. >> >> I will try and figure out the reason but wanted to at least make this >> issue >> more concrete. >> >> -- Michael Ennen
Re: Windows Build setupTools
Hi Michael, I did not had to setup any special variables and documented my steps at https://github.com/BestSolution-at/openjfx-build. I had trouble myself initially but the reason was that I ran the "gradle sdk" command from within a MSDOS-Shell but you really need to run it within cygwin. Tom On 21.12.17 06:40, Michael Ennen wrote: Some people were reporting that Windows builds are difficult to setup. I think this is due to the fact that the call to setupTools in buildSrc/win.gradle is in fact not working correctly. Invoking buildSrc/genVSproperties.bat directly prints the correct properties. However adding some debugging to setupTools it is clear that something is very wrong with it. This is the result: WINDOWS_VS_DEVENVDIR= WINDOWS_VS_DEVENVCMD=/VCExpress.exe WINDOWS_VS_VCINSTALLDIR= WINDOWS_VS_VSINSTALLDIR= WINDOWS_VS_MSVCDIR= WINDOWS_VS_INCLUDE= WINDOWS_VS_LIB= WINDOWS_VS_LIBPATH= WINDOWS_VS_PATH=; WINDOWS_VS_VER=120 WINDOWS_SDK_DIR= WINDOWS_SDK_VERSION= This is the reason people are needing to hard-code values for the properties below the call to setupTools. I am trying to debug what is actually wrong with setupTools but so far not making much progress. I tried this on my local Windows 10 machine and Appveyor VMs and the result is the same. I also read at least two mails in this list about needing to hard-code the properties, I am assuming it is for the same reason. I will try and figure out the reason but wanted to at least make this issue more concrete.