Mike,
Actually all the Jar Bundler is doing is moving the files into a specific
dir structure (dir name ending in .app) with an Info.plist file in the right
place. From the app point of view that is the same as I did however I wrote
an ant script to construct the structure so it runs anywhere. The end result
should be the same - you have a double-clickable app on the Mac.
I also sorted out things like the help files, and the about, quit and prefs
menu items.
If you can, could you test what Gerd sent out and let us know what you
think.
Neville
-----Original Message-----
From: squ...@li...
<squ...@li...>
To: squ...@li...
<squ...@li...>
Sent: Tue Jun 21 04:45:30 2005
Subject: [Squirrel-sql-users] Re: Mac package for new SQuirreL release
Glenn,
It would seem that what I've built can not be considered a "better" solution
given your criteria.
I built the Jar Bundle using an Apple Supplied tool called "Jar Bundler".
This tool can take a Pure Java Application and bundle it with some
description files into a special .app directory structure. This special
directory presents to the Mac user as a single executable. When
double-clicked, this Bundle executes the underlying Java Application. This
is similar in concept to a Windows .bat file that executes a Java
Application using "start" or javaw.exe but since the entire structure is
shipped as one unit you don't have the issues of broken paths when the
Application is moved from one drive/partition/directory to another.
My mechanism for Bundling SQuirreL for the Mac *IS* dependent on doing the
final build step (the Bundling step) on a Mac.
However, what we gain by doing this final step is a version of SQuirreL that
is byte-code compatible with the code created by the current
squirrel-sql-1.2beta6-install.jar, which can be launched by double clicking
on the "App File" or a shortcut, and which can live on the "Dock" bar.
I have not seen Neville's ant build solution yet, but I expect that some
special processing steps are performed in the build process, and that
launching the resulting SQuirreL application will require opening a shell,
cd'ing to a special directory and running a shell or ant script to bring up
the application.
From an ease-of-use standpoint double-clicking beats command line when the
interface is a GUI (IMNSHO). But perhaps Neville has a technique that I
don't know about (there's lots about the Mac that I don't know).
FWIW, removing the .bat and .sh files was not necessary, but since I was
building by hand I removed the extraneous items (sort of like someone who,
while creating a Windows-specific distribution, might be tempted to remove
the .sh file).
Mike
On Jun 20, 2005, at 4:03 PM, gwg wrote:
> Hi folks,
>
> Let me chime in with my 2 cents.
>
> - Mike and Neville have each come up with a method of getting SquirreL to
run
> on the Mac. These ways differ from each other. I do not understand
either of
> them because I am not familiar with the Mac.
>
> - I would like Mike and Neville each to look at what the other one has
done
> and decide together which is better for us to use and how to integrate it
into
> the product.
>
> - My criteria for "better" includes a "requirement" that Gerd or I can
create
> the package as part of the standard Ant build on a non-Mac machine. This
> means that no Mac-only tools be part of the process. It would probably be
> best to have a separate "build Mac" target which gets included in the
standard
> "build release" target.
>
> - It is important that the Mac build not be dependant on a 3rd party (ie:
> someone other than the administrator) to build so that it can be done in
an
> atomic fashion, and thus avoid the possibility of having slightly
different
> versions on the different machines.
>
> - I would prefer to not have to delete things as part of the Mac product
> build. If the build requires deleting things such as shell scripts from
the
> product, then so be it, but the standard product already contains startup
> scripts for both Linux and Windows, andthere is no problem because of
that. So
> unless there is a conflict that forces the Mac version to not have the
other
> pieces, I say leave them in.
>
> - All other things being equal, I would tend to prefer the solution that
is
> already integrated in the Ant script and already in CVS. If there is a
> simpler solution, then by all means let's use it, but if there is no gain
to
> be had by changing what is there, the let's leave it alone.
>
> Mike and Neville: Can you coordinate and build the appropriate Ant target?
> Thanks.
>
> Glenn
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Squirrel-sql-users mailing list
Squ...@li...
https://lists.sourceforge.net/lists/listinfo/squirrel-sql-users
--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for the
addressee. Access by any other party is unauthorised without the express
written permission of the sender. If you are not the intended recipient, please
contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
via e-mail return. If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender. 3166
--------------------------------------------------------------------------------
|