Jörg,
I don't think it will be very much work to bring service bundler code from JFX
packager into OpenJDK jpackager. Though I can't give you estimates on amount of
work needed to be done for this at the moment.
- Alexey
On 7/23/2018 7:47 AM, Buchberger, Joerg wrote:
Thanks for the
Thanks for the insight.
@Alexey: Then, how much work do you see in reactivating service bundler?
Cheers
Jörg
-Original Message-
From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com]
Sent: Donnerstag, 12. Juli 2018 01:09
To: Buchberger, Joerg ;
core-libs-dev@openjdk.java.net
Cc:
Since support for services/daemons was already in javapackager, why does this
have to be a stretch goal? Isn’t it mostly already done?
I would like to see this in the initial implementation. It is something I’m
currently using via javapackager.
I’m still trying to figure out the best strategy
We will likely be able to deliver the .exe installer (with its
dependency on Inno Setup).
As for the service bundler, this will be a "nice to have" (a stretch
goal) for this version, but isn't on the list of committed features.
Alexsei might be able to comment further on how much work it
Hi
thanks for the update/info. I had a quick look at the changes. So, here some
thoughts...
As described in JDK-8200758, and therefore expected, WinExeBundler has been
removed in favor of putting focus on WinMsiBundler.
(Although, I regret that decision - since my personal experience has been
For the first point, it means that jpackager should use jopt for the argument
parsing (to be fully compatible with the GNU style of options).
For the second point, it means to change a lot of code that may break because
it's less mechanical than introducing try-with-resources.
This seems
- Mail original -
> De: "Kevin Rushforth"
> À: "Remi Forax"
> Cc: "core-libs-dev" , "Alexey Semenyuk"
> , "Andy Herrick"
>
> Envoyé: Samedi 7 Juillet 2018 15:47:01
> Objet: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
> JDK-8200758: Packaging Tool]
> Hi
Hi Remy,
Thank you for taking a look.
Yes, the javapackager code that forms the basis for the jpackager
prototype was initially developed on older JDKs and evolved from there.
I'm sure the improvements you suggest are all good ones, and it doesn't
seem like it would be too hard to address
I've just taking a look at the patch,
i don't see how this can be integrated soon, the code is consistently
inconsistent as one of my colleague would say, even the coding conventions are
not respected.
i believe that's it's because the code have been written first in Java 6 an
without
