IcedTeaWeb: using java 9 run args ?
Laurent Bourgès
bourges.laurent at gmail.com
Fri Feb 8 15:26:49 UTC 2019
Hi Jiri,
I easily merge with your latest changes and it builds properly.
(I noticed build generated the win-deps folder now)
Here is the updated patch.
Cheers,
Laurent
Le jeu. 7 févr. 2019 à 18:45, Laurent Bourgès <bourges.laurent at gmail.com> a
écrit :
> Jiri,
>
> Le jeu. 7 févr. 2019 à 17:12, Jiri Vanek <jvanek at redhat.com> a écrit :
>
>> So the cross-build-bats is pushed.
>>
>
> Yes I got the notification, thx.
>
>
>> I will elaborate on rest tomorrow.
>> I yu adapt your patch to current head, it will be significant help.But is
>> not necessary.
>>
>
> I will try merging tomorrow as I stay at home (flu).
>
> Thank you too
> Laurent
>
>>
>> TYVM for cooperation!
>> J.
>>
>>
>> On 2/7/19 3:47 PM, Laurent Bourgès wrote:
>> > Hi Jiri,
>> > Good to have your feedback.
>> >
>> >
>> > Le jeu. 7 févr. 2019 à 14:27, Jiri Vanek <jvanek at redhat.com <mailto:
>> jvanek at redhat.com>> a écrit :
>> >
>> > Hi Laurent!
>> >
>> > How are we with this?
>> >
>> >
>> > I prefer you to do its integration as my patch has conflicts with your
>> changes (am) and my changes
>> > are too big so splitting patch is needed, I agree.
>> >
>> >
>> > Can I commit my "crosscompile" bats patch, and will you adapt?
>> > Maybe it woudl be better if you first adapt your patch to my
>> crosscompile patch before I push - to
>> > test it abit.
>> > Or do you suggest any other workflow?
>> >
>> >
>> > Ok for me, I will follow and merge. If anything is wrong or missing, I
>> will propose smaller patches,
>> > sorry.
>> >
>> >
>> > After crosscompile patch is in, I 'm most likely +1 for pushing
>> your new bat+the work on @arg file
>> > (wiht some tuning on my side before push).
>> >
>> >
>> > Excellent plan.
>> >
>> >
>> > Until now I have not found better solution for jigsaw and other
>> params, so also rust launchers will
>> > do as you do - on jdk9+, will add this @file to java cmd. That will
>> be done as separate changeset
>> > (by me)
>> >
>> >
>> > Sounds good and easier to do in rust.
>> >
>> > Thanks a lot.
>> >
>> > Laurent
>> >
>> >
>> > Thanx!
>> > J.
>> > On 1/30/19 3:46 PM, Laurent Bourgès wrote:
>> > > Hi Jiri,
>> > >
>> > > > I finally finished rewriting / unify windows batch script
>> with linux
>> > > > shell script.
>> > > >
>> > > Taht is bat scripting masterpiece. Congratualtions for
>> gaining eternal patience.
>> > >
>> > >
>> > > thanks.
>> > >
>> > >
>> > > > Changes:
>> > > > - Xnofork is no more needed on windows because argument
>> parsing is working now
>> > > > - use run-args + fix classpaths (portable itw with deps)
>> > > > - fix CRLF in bat files
>> > >
>> > >
>> > > One remaining difference: windows batch does not parse
>> deployment.properties (to look up JVM)
>> >
>> >
>> > This is ok, I do not intend to add it. If anybody wish, anybody
>> can. And yes, JAVA_HOME can
>> > help a lot.
>> > >
>> > > The crlg hack is necessary only for args file. That really
>> have to be another patch for that.
>> > > (still we can keep the thread, as many was told here already))
>> > >
>> > >
>> > > I think the contrary, only batch files really expect CRLF line
>> endings. if you edit using
>> > notepad or
>> > > if you use echo "text" then the line ending is important.
>> > > I suppose jvm arg file are well handled by jvm concerning line
>> endings, so it is not required to
>> > > have CRLF in launcher_run.args.
>> > >
>> > > I agree some changes to Makefile.am could be postponed to another
>> patch.
>> > >
>> > >
>> > > >
>> > > > I tested it on windows 7/10 and it works great.
>> > > > I noted windows shortcuts work now, except on JDK12 (maybe
>> related to
>> > > > jigsaw classloader ?)
>> > >
>> > > No idea. Adding Joel. to CC. Maybe you will be able to look
>> into it?
>> > > Alex quite IcedTea recently, so there is no windows guy
>> around. I will try to get help in
>> > RH with
>> > > windows, otherwise windows "support" of itw will depend
>> purely on community.
>> > >
>> > >
>> > > >
>> > > > I have questions about header variables (too many) and why
>> these need
>> > > > to be absolute paths ?
>> > > Because in distribution, they ecan be anywhere.
>> > >
>> > > > it could be relative paths if we add ITW_HOME on the top.
>> > > > Of course, it depends between DIST or BUNDLE modes ... like
>> for
>> > > > dependencies (win/linux_deps folders)
>> > > Yes. Bundle mode will be more happy with a bit different
>> setup. Maybe ITW will once grow
>> > to be more
>> > > standalone then distributions frindly.
>> > >
>> > >
>> > > OK, but it means bundle support needs to re-compute path relative
>> to ITW_HOME on linux & windows.
>> > > In this case, it is not obvious to guess the relative path to a
>> resource from its absolute
>> > path and
>> > > lots of path are hard-coded in windows batch.
>> > > For example:
>> > > set "BINARY_LOCATION=%ITW_HOME%/bin/%PROGRAM_NAME%.bat"
>> > >
>> > > set
>> "SPLASH_LOCATION=%ITW_HOME%/share/icedtea-web/javaws_splash.png"
>> > >
>> > > It is not good, as ITW resource may be moved in Makefile or by
>> installer, so these paths /
>> > variables
>> > > must be maintained if any file is renamed or moved (netx.jar ->
>> javaws.jar recently !)
>> > >
>> > > Any idea ? It is possible to provide both absolute path &
>> relative paths but it will be too ugly &
>> > > complicated.
>> > >
>> > >
>> > > >
>> > > > Please explain how do you plan to make portable
>> (cross-platform) packages ?
>> > > Nothing like that!
>> > > I will build (and I already am) linux tarablls on linux, and
>> windows tarballs on windows.
>> > >
>> > >
>> > > In my tests, I build on linux with batch generated (wrong paths
>> inside) then create a zip file
>> > with
>> > > linux/win deps.
>> > > It works on windows using bundle mode (ITW_HOME pointing to the
>> script dir).
>> > > Here is my do-package.sh script (post-build):
>> > > ITW_HOME=./install/
>> > > mkdir -p $ITW_HOME/linux-deps-runtime/
>> > > mkdir -p $ITW_HOME/win-deps-runtime/
>> > >
>> > > # add rhino ?
>> > >
>> > > # linux:
>> > > cp tagsoup-1.2.1.jar $ITW_HOME/linux-deps-runtime/
>> > >
>> > > # windows:
>> > > cp tagsoup-1.2.1.jar $ITW_HOME/win-deps-runtime/
>> > > cp mslinks.jar $ITW_HOME/win-deps-runtime/
>> > >
>> > > zip -r itw-1.8-install.zip $ITW_HOME
>> > >
>> > >
>> > > I had attached my version of crosscompiler bats on linux.
>> Compared to yours, thay are true on
>> > > windows. Not sure how you were handluing this case. Otherwise
>> they loks same asyours. I
>> > wrote them
>> > > in Monday, but then fell down with flue which keeps
>> persisting.
>> > >
>> > >
>> > > Yes it is really close. As I am not an automake expert, I prefer
>> your approach (true on windows).
>> > > I will merge your changes and adapt my Makefile patch with less
>> changes (LUNCHERS -> LAUNCHERS,
>> > > run-args, fix CRLF in batch files)
>> > >
>> > >
>> > >
>> > > Also i noticed, that *image* as done on linux, with
>> crosscompile on, is useless on
>> > windows. Yes,
>> > > you have bats, but windows-deps directory is corrupoted from
>> linux build.
>> > > Whre I wont to keep this state on 1.7, in head, the only
>> possible solution ois to get rid of
>> > > linux/windows*deps*dirs and replace them by singledir deps.
>> WDYT?
>> > >
>> > >
>> > > I can not build on windows, so I am making a cross-platform
>> package on linux (jar files +
>> > resources
>> > > + shell launchers).
>> > > I agree it would be simpler to put dependencies in a single
>> location (jar files are
>> > cross-platform).
>> > >
>> > >
>> > > In addition, yours patch contains also the arg file. I
>> probably agree that it is way to
>> > go. This
>> > > will do its job for shell launchers. For rust ones, I will
>> need to add the cp/bootcp and
>> > other java
>> > > switches customisation properties into deployment.properties.
>> WDYT?
>> > >
>> > >
>> > > The aim consist in having all ITW jigsaw args (add-reads /
>> add-opens) gathered in a single
>> > place and
>> > > minimize the jvm args.
>> > > I wonder if rust launchers could do the same (use
>> @launchers-run.args) and only customize the
>> > > --patch-moduleargs (netx,plugin,js) and of course, bootclasspath
>> + classpath (absolute paths)
>> > >
>> > >
>> > > >
>> > > > PS2: you can have a look @github to see complete shell
>> scripts (not diff):
>> > > >
>> https://github.com/bourgesl/icedtea-web/tree/run-args/shell-launcher
>> > >
>> > > h<t is really splendid work. I\m unable to have nay comment
>> to new bat file, except that
>> > it loosk
>> > > much better then old one, and that it do not looks
>> malicious:)
>> > >
>> > >
>> > > Yes I mimic the linux behaviour (functional blocks); only the JVM
>> lookup (from
>> > deplyoment.properties
>> > > is not handled).
>> > >
>> > >
>> > > I'm for its incorporation to both head and 1.7
>> > >
>> > > Great !
>> > >
>> > >
>> > > Few comments to ther chnegs inline:
>> > > ...
>> > > >
>> > > > patch-run-args-win.2.diff
>> > >
>> > > All refactorings/untypos must go as separate patch. Sorry.
>> Feel free topush them without
>> > any other
>> > > review. They are making reading of this hard.
>> > >
>> > >
>> > > Please be more precise. You mean fixing typos in Makefile.am
>> (luncher -> launcher) ?
>> > >
>> > >
>> > > > +if ENABLE_WIN_SHELL_LAUNCHERS
>> > > > +# convert Unix newlines (LF) to DOS format:
>> > > > + line_end_edit_launcher_script=-e "s/\$$/\r/"
>> > > > +else
>> > > > + line_end_edit_launcher_script=
>> > > > +endif
>> > >
>> > > Only for args file path, right?
>> > >
>> > > No, it only fix generated batch files.
>> > >
>> > >
>> > > > +if "%MODULAR_JDK%" == "YES" (
>> > > > + rem warning extra escaping
>> > > > + set "MODULAR_ARGS=--patch-module
>> "java.desktop=%NETX_JAR%;%PLUGIN_JAR%""
>> > >
>> > > why NETX.JAR?
>> > >
>> > >
>> > > %NETX_JAR% means $NETX_JAR ie .../javaws.jar
>> > > It is required to patch jdk.desktop module with ITW code (jigsaw
>> issue as before).
>> > >
>> > >
>> > >
>> > > > +# Support Modular JDK (jigsaw):
>> > > > MODULAR_JDK="NO"
>> > > > -version=`${JAVA} -version 2>&1 | head -n 1 | cut -d'-' -f1
>> | cut -d'"' -f2 | cut -d'.' -f1`
>> > > > +fullversion=`${JAVA} -version 2>&1`
>> > > > +echo "fullversion: $fullversion"
>> > >
>> > > I would skipp the fullversion: string, and printed
>> $fullversion to stderr as are people
>> > used from
>> > > jdk/ (?)
>> > >
>> > >
>> > > Not understood. I wanted to avoid calling java -version twice and
>> but show JVM version once.
>> > > What do you propose ?
>> > >
>> > >
>> > > >
>> > > > +#echo "CMD: ${COMMAND[@]}"
>> > >
>> > > The commented echo is weird. One is usually running this in
>> -x subshell to see details.
>> > >
>> > >
>> > > Ok I will remove such debugging lines.
>> > >
>> > > PS: Would it sound possible for you to handle merging & pushing
>> this patch ?
>> > > Anyway I will wait for your changes to Makefiles before merging.
>> > >
>> > > Cheers,
>> > > Laurent
>> >
>> >
>> > --
>> > Jiri Vanek
>> > Senior QE engineer, OpenJDK QE lead, Mgr.
>> > Red Hat Czech
>> > jvanek at redhat.com <mailto:jvanek at redhat.com> M: +420775390109
>> >
>>
>>
>> --
>> Jiri Vanek
>> Senior QE engineer, OpenJDK QE lead, Mgr.
>> Red Hat Czech
>> jvanek at redhat.com M: +420775390109
>>
>
--
--
Laurent Bourgès
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190208/a4b9d29d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-run-args-win.3.diff
Type: text/x-patch
Size: 29884 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190208/a4b9d29d/patch-run-args-win.3-0001.diff>
More information about the distro-pkg-dev
mailing list