Hi Scott,
thank you for you answer and explainationr, I did another test the
weekend, with a JFrame Window and this is shown.
Thomas
Am 16.12.2019 um 02:46 schrieb Scott Palmer:
Welcome to Windows.
The .exe is a Windows app not a Console app. This is a distinction that only
Microsoft seemed
I 've tried with the recommended jpackage from JDK14 EA.
The syntax has slightly changed, with the option --win-console it now
shows the output as expected:
> .\test01.exe
Dec 16, 2019 6:41:01 PM simpleapp.SimpleApp main
INFO: SimpleApp says hello
Thomas
Am 16.12.2019 um 15:14 schrieb Andy H
nsole option.
Jonas
-Ursprüngliche Nachricht-
Von: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] Im Auftrag
von Thomas Vatter
Gesendet: Montag, 16. Dezember 2019 15:44
An: core-libs-dev@openjdk.java.net
Betreff: Re: jpackager
I first read on
https://openjdk.java.net/jep
15:44
An: core-libs-dev@openjdk.java.net
Betreff: Re: jpackager
I first read on
https://openjdk.java.net/jeps/343
Then I was looking for the download and somewhere found the links
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11
I first read on
https://openjdk.java.net/jeps/343
Then I was looking for the download and somewhere found the links
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11
That was my initial reaction too, but I don't believe that is the
problem here.
The arguments to jpackage used indicate you are using an older early
access version of jpackage.
Can you try again using the jpackage in the latest JDK14 EA from
https://jdk.java.net/14/ ?
/Andy
On 12/15/2019
Welcome to Windows.
The .exe is a Windows app not a Console app. This is a distinction that only
Microsoft seemed to think was needed. All other platforms are sane.
There is command line option to make a console app.
--win-console
Scott
> On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrot
Hi,
I've created a modular jar and jre image by jlink.
I tested it with this command:
PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp
Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main
INFO: SimpleApp says hello
It says "SimpleApp says hello" in the powershell window.
Then I p
Looks good.
/Andy
On 10/17/2019 10:03 PM, Alexey Semenyuk wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8231972
[2] http://cr.openjd
Looks good.
On 10/17/19 7:03 PM, Alexey Semenyuk wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8231972
[2] http://cr.openjdk.java.net
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Alexey
[1] https://bugs.openjdk.java.net/browse/JDK-8231972
[2] http://cr.openjdk.java.net/~asemenyuk/8231972/webrev.00/
Looks good.
On 8/9/2019 9:31 AM, Alexey Semenyuk wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Add build flag to statically link exe wrapper for msi files with MS
runtime lib.
[1] http
looks good.
/Andy
On 8/9/19 12:31 PM, Alexey Semenyuk wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Add build flag to statically link exe wrapper for msi files with MS
runtime lib.
[1
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Add build flag to statically link exe wrapper for msi files with MS
runtime lib.
[1] https://bugs.openjdk.java.net/browse/JDK-8229334
[2] http://c
looks good
/Andy
On 6/28/2019 10:03 PM, Alexander Matveev wrote:
Hi,
http://cr.openjdk.java.net/~almatvee/8224486/webrev.01/
- Original fix was missing (not sure why) setting Java options map
flag to allow duplicates. Without it fix does not work. See
OrderedMap.h line 92 and 261 and Packa
Hi,
http://cr.openjdk.java.net/~almatvee/8224486/webrev.01/
- Original fix was missing (not sure why) setting Java options map flag
to allow duplicates. Without it fix does not work. See OrderedMap.h line
92 and 261 and Package.cpp.
- Old loop is kept to avoid possible regression in case if we
then I'm fine with original fix.
/Andy
On 6/25/2019 6:08 PM, Alexander Matveev wrote:
Hi Alexey,
I cannot use index to get items from map. At least I did not figure it
out how to do this. We need to use iterator when getting values from map.
Thanks,
Alexander
On 6/25/2019 4:52 AM, Alexey
Hi Alexey,
I cannot use index to get items from map. At least I did not figure it
out how to do this. We need to use iterator when getting values from map.
Thanks,
Alexander
On 6/25/2019 4:52 AM, Alexey Semenyuk wrote:
In
http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackag
I'm fine with this either way.
The ini file will have GetAllowDuplicates() true, but any OrderedMap
that doesn't will have count of 1.
/Andy
On 6/25/2019 7:52 AM, Alexey Semenyuk wrote:
In
http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/Ja
In
http://cr.openjdk.java.net/~almatvee/8224486/webrev.00/src/jdk.jpackage/share/native/libapplauncher/JavaVirtualMachine.cpp.sdiff.html,
JavaOptions::AppendValues(), why do we need branching based on the
result of Values.GetAllowDuplicates()? Why can't we use the same logic
that was introduced
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Duplicated Java options were not read correctly from OrderedMap,
instead we read only unique from map. Fixed by reading duplicated Java
options.
[
Hi,
The copyright in CommandLine.java should be 2019, the package
declaration changed,
though probably nothing else.
$.02, Roger
On 02/26/2019 08:35 AM, Kevin Rushforth wrote:
Looks good to me.
-- Kevin
On 2/26/2019 5:20 AM, Andy Herrick wrote:
Please review the jpackage fix for bug [1]
Looks good to me.
-- Kevin
On 2/26/2019 5:20 AM, Andy Herrick wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
The fix is to include the code for processing @argfile from javac into
jpackag
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
The fix is to include the code for processing @argfile from javac into
jpackage.
[1] https://bugs.openjdk.java.net/browse/JDK-8219695
[2] http://cr.
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 t
: Alexey Semenyuk ; Andy Herrick
Subject: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
JDK-8200758: Packaging Tool]
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 hav
gt; or coming back in at all?
>>
>> Cheers
>> Jörg
>>
>>
>> -Original Message-
>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
>> Behalf Of Kevin Rushforth
>> Sent: Freitag, 6. Juli 2018 22:14
>> To:
Juli 2018 22:14
To: core-libs-dev@openjdk.java.net
Cc: Alexey Semenyuk ; Andy Herrick
Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new
'JDK-8200758-branch' branch i
...@openjdk.java.net] On Behalf
Of Kevin Rushforth
Sent: Freitag, 6. Juli 2018 22:14
To: core-libs-dev@openjdk.java.net
Cc: Alexey Semenyuk ; Andy Herrick
Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal:
JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool 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
- 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/sandb
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
o start an OpenJDK project for it and
iterate on the code before trying to include it in the JDK. For me, the code is
too big to use the jdk/sandbox.
regards,
Rémi
- Mail original -
> De: "Kevin Rushforth"
> À: "core-libs-dev"
> Cc: "Alexey Semenyuk"
An initial prototype of the jpackager tool has been pushed to a new
'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is
interested in taking a look, you can clone it as follows:
hg clone http://hg.openjdk.java.net/jdk/sandbox
cd ./sandbox
hg update JDK-8200
34 matches
Mail list logo
