[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    JavaFX Maven Plugin
From:       zonski () gmail ! com (Daniel Zwolenski)
Date:       2012-11-28 12:48:58
Message-ID: CANbPsPxR+CcfurpeGJ0EyJ3T_qgD=TAwixuriqMzomURkW6=SA () mail ! gmail ! com
[Download RAW message or body]

I have the Maven plugin assembling an 'exploded' distro for windows (what I
think the JFX tools calls an 'image') as the pre-step to building an MSI
with WiX.

My exploded bundle looks like:

  .\WinLauncher.exe (pulled from %java_home%/ant-javafx.jar at build time)
  .\app (contains all my jar files)
  .\app\package.cfg (text file with a "mainjar" referencing my main
executable jar in app dir)
  .\runtime\jre  (full copy of %JAVA_HOME% at build time)

When I run WinLauncher.exe I get a dialog saying "no main class" and the
title of the dialog is "Expected to find com.javafx.main.MainClass".

So I'm guessing the launcher is hardcoded to look for the JavaFX
pre-launcher and not the one specified in the manifest of the main
executable JAR? I was hoping to avoid the pre-launcher in my assembly (just
adds more mess). I'm assuming there's no way to make the Launcher just run
my JAR without the pre-launcher, nice and simple like?

Any reason why the pre-launcher is needed at all if the JRE is co-bundled.
I thought the job of the pre-launcher was to make sure you had the right
JRE and JFX, etc, which seems somewhat unnecessary when you have a
co-bundled JRE. Does it do anything else?

Another question, does the native bundle have to work off a single
"uber-jar" or can I have all my individual JARs sitting in the "app"
directory outside of my main app jar? I very much hope it is the latter.
Where does the app get it's classpath from (unfortunately no decompiler for
WinLauncher.exe so I'm flying blind on some of this).

And since I'm asking, the JFX packager looks to filter files when it copies
the JRE into the bundle (I think that's what the "Rule" thing is doing
anyway). Is this just to save space or for some other reason? I can't see
any real pattern to the choice of files being excluded, is there one?

I can probably work all of the above out through continual trial and error,
etc, but if anyone has time to throw some insight my way I'd appreciate it.

Thanks,
Dan












On Tue, Nov 27, 2012 at 9:33 AM, Daniel Zwolenski <zonski at gmail.com> wrote:

> Ignore that bit about needing it open sourced to get the launch exe out -
> I was being stupid, I should be able to extract it from the JDK directly,
> dodging the legal issues. I will need the launcher code for AU though
> eventually and it would be nice to be able to read through the code without
> using a decompiler.
>
> I think I can do nearly everything I need to by myself (just going to take
> a heap of work) except for one thing that would open up a lot more options:
>
> If the JRE for each platform was available as a zip for download from
> somewhere public (i.e. that an automated program could download - none of
> that annoying "accept the licence" thing) then this opens the road to
> cross-platform native distros and simpler builds. It doesn't have to be in
> a Maven repo, it can still have the same licencing restrictions, it just
> needs to be publicly available without stop-gates in the way (e.g. a simple
> download from java.com).
>
> Technically this should be ridiculously easy and I think it would benefit
> the regular JFX deployment tools a lot too. I could actually create the
> zips but I'm not allowed to "distribute" the JRE, I can only "include" it
> in my app.
>
> The easiest way around this is for Oracle to be the distributor (as it is
> now) but just provide (a) the download as a zip file for each platform and
> (b) a way to download these zips without having to tick the "I accept the
> licence" thing on the web page.
>
> I know the second part will be the tricky one (kill all the lawyers) but
> if someone from Oracle (e.g. the JavaFX packaging team) could do some
> pushing, maybe it could happen sometime in the next year or two?
>
>
>
>
>
>
> On Mon, Nov 26, 2012 at 8:13 AM, Jim Weaver <james.weaver at oracle.com>wrote:
>
>> Daniel,
>>
>> +1 to Scott's sentiments about being glad that you're contributing to the
>> vitally important JavaFX deployment effort!
>>
>> Thanks,
>> Jim Weaver
>>
>> On Nov 25, 2012, at 2:25 PM, Scott Kovatch <scott.kovatch at oracle.com>
>> wrote:
>>
>> > On Nov 25, 2012, at 3:29 AM, Daniel Zwolenski <zonski at gmail.com> wrote:
>> >
>> >> Hey guys,
>> >>
>> >> Is there any more news on the open sourcing of the packaging tools?
>> It's
>> >> been a "few days away" since October 27.
>> >>
>> >> What I'd really like to not have to rewrite are the native launcher
>> >> executables that get bundled into the installers (i.e. the "exe" on
>> >> windows). I can rip these out of the Java bundle for now to do my
>> >> development but I won't be able to release my improved bundler until
>> these
>> >> bits are open sourced, giving me the legal all clear to include them
>> in my
>> >> plugin.
>> >>
>> >> Any chance I could get an actual timeframe on when the packaging tools
>> are
>> >> to be open sourced?
>> >
>> > I'm chugging along with this, but I was off last week due to the US
>> Thanksgiving holiday.
>> >
>> > The code has been cleaned up (read: commented, TODO's removed/bugs
>> created) and ready for review. There is some code we want to retire as part
>> of this process, and that means modifying some makefiles and ensuring
>> everything builds correctly in the closed repository, and then we can move
>> it to the open  rt project in OpenJFX and make sure it builds there.
>> >
>> > So, it's happening, but there were some changes in assumptions I have
>> to work around. Releasing something that won't build isn't helpful. I'll
>> have a better timeframe early this week.
>> >
>> >> I'm doing my best to contribute what I personally think is vitally
>> >> important for JavaFX. In general I'm accepting of the fact that what
>> I'm
>> >> doing is not something Oracle sees as overly important and I'm on my
>> own
>> >> (it's been quite a liberating attitude to take to be honest). Open
>> Sourcing
>> >> the packaging tools however, was something you said you were going to
>> do
>> >> anyway and it would save me having to write a whole new native
>> launcher for
>> >> each platform.
>> >
>> > I think it's great that you're interested in working on this.
>> Deployment is not a glamorous job but it needs to be done. Without it, the
>> rest of JavaFX isn't as useful, IMO.
>> >
>> > What we want to do is have a core API that's as tool-ignorant as
>> possible, and then let developers like you put the tool frameworks around
>> it. Right now we're closely tied to ant, and I'd like to get away from that.
>> >
>> > -- Scott K.
>> >
>> > ------------------------
>> > Scott Kovatch
>> > Oracle
>> > Pleasanton, CA
>> >
>>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]