[icedtera-web] future of shell launchers

[Laurent Bourgès]

Yes please go ahead.
I am still overbusy / tired, so I miss this train !
Will find some time very soon to look at itw launchers.

Sorry,
Laurent

Le lun. 14 janv. 2019 à 16:45, Jiri Vanek <jvanek at redhat.com> a écrit :

> I will push this soon to head. Hopefully it will be positive change.
> If it proves itself, it willgo ti 1.7.
>
> Any feedback still welcomed, another patche sin this area will flow
>
> J.
> On 12/18/18 2:47 PM, Jiri Vanek wrote:
> > Hi!
> >
> > There is quite minimalist change to make itw shell lunchers portable out
> of distribution world.
> > I think it is feasable also for 1.7.
> >
> > It should be consistent iwth current windows bats, and I will align
> future rust ones too.
> >
> >
> > J.
> >
> > On 12/17/18 12:03 PM, Laurent Bourgès wrote:
> >> Hi Jiri,
> >>
> >> It looks very promising, but I have to figure out the transition plan.
> >>
> >> Would you accept to talk directly (skype?) to help going forward ?
> >>
> >> Laurent
> >>
> >> Le lun. 17 déc. 2018 à 10:52, Jiri Vanek <jvanek at redhat.com <mailto:
> jvanek at redhat.com>> a écrit :
> >>
> >>
> >>
> >>     Hi Laurent!
> >>
> >>     Maybe a bit more constructive answer to you query.
> >>     You could noticed, than in rust lunchers(patch still on review), we
> are not using make-generated
> >>     classpath, but instead are sent in individual jars.
> >>     I think they are much more versatile for various changes of paths.
> >>     usage of those will make (boot)classpaths composing in bats easier,
> and allows better implementation
> >>     of ITW_HOME into linux shells.
> >>     I have very good experience with resolvig scripts dir with
> following snippet[1].
> >>     So the workflow can be:
> >>     1)adding [1] to both head and 1.7
> >>     2)change shell launchers in 1.8 to accept parameters whcih are
> flowing to rust lunchers
> >>     3)in 1.8 compose classapths honor variables in same manner as rust
> lucnhers do
> >
> > 3.5 "cross compile" launchers.
> >>     4)adapt non breakig parts of 2 an 3  in 1.7. namely hack (sed in
> (boot)cps>) the usage og  [1]'s
> >>     SCRIPT_DIR and  bat's ITW_HOME
> >>       - postpond posisble dangerous parts to 1.7.3
> >>     In meantime, finish .args file handling everywhere. Especially in
> 1.8.
> >>
> >>     Thoughts?
> >>
> >>
> >>     [1]
> >>     ## resolve folder of this script, following all symlinks,
> >>     ##
> http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what-directory-its-stored-in
> >>     SCRIPT_SOURCE="${BASH_SOURCE[0]}"
> >>     while [ -h "$SCRIPT_SOURCE" ]; do # resolve $SOURCE until the file
> is no longer a symlink
> >>       SCRIPT_DIR="$( cd -P "$( dirname "$SCRIPT_SOURCE" )" && pwd )"
> >>       SCRIPT_SOURCE="$(readlink "$SCRIPT_SOURCE")"
> >>       # if $SOURCE was a relative symlink, we need to resolve it
> relative to the path where the symlink
> >>     file was located
> >>       [[ $SCRIPT_SOURCE != /* ]] &&
> SCRIPT_SOURCE="$SCRIPT_DIR/$SCRIPT_SOURCE"
> >>     done
> >>     readonly SCRIPT_DIR="$( cd -P "$( dirname "$SCRIPT_SOURCE" )" &&
> pwd )"
> >>     --
> >>     Mgr. Jiri Vanek
> >>     judovana at email.cz <mailto:judovana at email.cz>
> >>
> >
> >
>
>
> --
> Jiri Vanek
> Senior QE engineer, OpenJDK QE lead, Mgr.
> Red Hat Czech
> jvanek at redhat.com    M: +420775390109
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190114/87e9e86b/attachment-0001.html>