IcedTeaWeb: using java 9 run args ?
Laurent Bourgès
bourges.laurent at gmail.com
Tue Feb 12 09:58:50 UTC 2019
Hi Jiri,
> I had harm your patch a bit.
> I made the location configurable, as I cannot enforce linux distros to
> have the args file in bin folder.
>
> Still I kept the default of yours - bin.
>
> That naturally went to issue with searching for args file outside the
> distro world. So I added one
> more copy into win/linux static images.
>
> WDYT?
>
I had a quick look (not tested) and it looks good.
I noticed you forgot to replace 1 hard-coded value in windows batch file:
+ set "RUN_ARGS_LOCATION=%ITW_HOME%/bin/launchers-run.args"
should be
+ set "RUN_ARGS_LOCATION=%ITW_HOME%/bin/itw-modularjdk.args"
>
>
> IN addition I had renamed the variables to have common root, and properly
> used variable instead of
> hardcoded filename.
>
> WDYT?
>
OK, except the typo.
Will test it soon or after you push the patch.
Laurent
> Thanx for patience. Unless you have much more objections, I will push for
> you tomorrow. (+rust
> launchers)
>
> J.
> On 2/8/19 4:26 PM, Laurent Bourgès wrote:
> > 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
> > <mailto:bourges.laurent at gmail.com>> a écrit :
> >
> > Jiri,
> >
> > Le jeu. 7 févr. 2019 à 17:12, Jiri Vanek <jvanek at redhat.com <mailto:
> 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>
> > <mailto: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> <mailto:
> 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 <mailto:jvanek at redhat.com> M: +420775390109
> >
> >
> >
> > --
> > --
> > Laurent Bourgès
>
>
> --
> 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/20190212/0066b6fa/attachment-0001.html>
More information about the distro-pkg-dev
mailing list