Thread: [Rails-devel] Mac OS X

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Out of curiousity, are there other Rails users who use Mac OS X, or any
other non-Windows platform (Unix) for that matter?

Freek

Freek Dijkstra wrote:
> Out of curiousity, are there other Rails users who use Mac OS X, or any
> other non-Windows platform (Unix) for that matter?
>   
Yes.  Mac and Ubuntu Linux.   My Mac complains when compiling but this 
does not seem to affect the running of rails.  I will send the Mac's 
complaint to the list when I am at that computer.

-- 
Rick Westerman wes...@pu...

Yes, I use Mac OS X Snow Leopard and Ubuntu Linux Karmic Koala.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Jan 28, 2010 at 12:34 PM, Freek Dijkstra <sf_...@ma...>wrote:

> Out of curiousity, are there other Rails users who use Mac OS X, or any
> other non-Windows platform (Unix) for that matter?
>
> Freek
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

I use Windows XP when I'm at work, but use Debian Lenny (linux) when
at home (and I'm having a hell of time getting rails to read the
config file on my Debian box).

Steve Undy
st...@ro...

On Thu, Jan 28, 2010 at 1:48 PM, Chris Shaffer <chr...@gm...> wrote:
> Yes, I use Mac OS X Snow Leopard and Ubuntu Linux Karmic Koala.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Thu, Jan 28, 2010 at 12:34 PM, Freek Dijkstra <sf_...@ma...>
> wrote:
>>
>> Out of curiousity, are there other Rails users who use Mac OS X, or any
>> other non-Windows platform (Unix) for that matter?
>>
>> Freek
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term contracts
>> Personal 24x7 support from experience hosting pros just a phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Mac OS X Snow Leopard.  -Chris

Freek Dijkstra wrote:
> Out of curiousity, are there other Rails users who use Mac OS X, [..]

That's more people than I anticipated. Is there interest in making the
GUI a bit more native?

I just gave it a shot. Here is a screenshot:
http://www.macfreek.nl/temp/MacRails.png

And here is the download:
http://www.macfreek.nl/temp/MacRails-1.1.2.zip
(Insert obligatory warning about the risk of executing programs you
download from the web, especially if they are advertised by someone
called Freek ;) )

It is possible to build this Mac automatically (even on Linux or
Windows), I'll post the patch for build.xml in a separate mail.

Be aware that this is a very, very basic attempt. Yes, the menu bar is
there, but somehow, it is only working if the Status Window is in the
foreground, not when the Map Windows is shown. The menu shortcuts still
use ^/⌥ (control) instead of ⌘ (command) for the modifier keys, etc. In
fact, I have not changed a single line of code yet. That would be
necessary to give it a more native feel. But at least it's a start.

Regards,
Freek

One of the players in our current game has been making Ruby scripts to
automate startup, directory setting, autoloading of the current game file,
autonotification of the next player using Mail.app, etc.  We're just waiting
for him to automate taking our turns.  (OK, I stole that joke from Chris
Brooks...)

If there's any interest, perhaps we can persuade him to share his scripts
once they're more thoroughly tested?

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Jan 28, 2010 at 4:09 PM, Freek Dijkstra <sf_...@ma...>wrote:

> Freek Dijkstra wrote:
> > Out of curiousity, are there other Rails users who use Mac OS X, [..]
>
> That's more people than I anticipated. Is there interest in making the
> GUI a bit more native?
>
> I just gave it a shot. Here is a screenshot:
> http://www.macfreek.nl/temp/MacRails.png
>
> And here is the download:
> http://www.macfreek.nl/temp/MacRails-1.1.2.zip
> (Insert obligatory warning about the risk of executing programs you
> download from the web, especially if they are advertised by someone
> called Freek ;) )
>
> It is possible to build this Mac automatically (even on Linux or
> Windows), I'll post the patch for build.xml in a separate mail.
>
> Be aware that this is a very, very basic attempt. Yes, the menu bar is
> there, but somehow, it is only working if the Status Window is in the
> foreground, not when the Map Windows is shown. The menu shortcuts still
> use ^/⌥ (control) instead of ⌘ (command) for the modifier keys, etc. In
> fact, I have not changed a single line of code yet. That would be
> necessary to give it a more native feel. But at least it's a start.
>
> Regards,
> Freek
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

I'm not a huge fan of Ruby (I prefer Python), but I won't turn
contributions away just because of language zealotry. ;-)

Feel free to encourage him to subscribe to the list and share his work.

---Brett.

On Thu, Jan 28, 2010 at 4:13 PM, Chris Shaffer <chr...@gm...> wrote:
> One of the players in our current game has been making Ruby scripts to
> automate startup, directory setting, autoloading of the current game file,
> autonotification of the next player using Mail.app, etc.  We're just waiting
> for him to automate taking our turns.  (OK, I stole that joke from Chris
> Brooks...)
>
> If there's any interest, perhaps we can persuade him to share his scripts
> once they're more thoroughly tested?
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Thu, Jan 28, 2010 at 4:09 PM, Freek Dijkstra <sf_...@ma...>
> wrote:
>>
>> Freek Dijkstra wrote:
>> > Out of curiousity, are there other Rails users who use Mac OS X, [..]
>>
>> That's more people than I anticipated. Is there interest in making the
>> GUI a bit more native?
>>
>> I just gave it a shot. Here is a screenshot:
>> http://www.macfreek.nl/temp/MacRails.png
>>
>> And here is the download:
>> http://www.macfreek.nl/temp/MacRails-1.1.2.zip
>> (Insert obligatory warning about the risk of executing programs you
>> download from the web, especially if they are advertised by someone
>> called Freek ;) )
>>
>> It is possible to build this Mac automatically (even on Linux or
>> Windows), I'll post the patch for build.xml in a separate mail.
>>
>> Be aware that this is a very, very basic attempt. Yes, the menu bar is
>> there, but somehow, it is only working if the Status Window is in the
>> foreground, not when the Map Windows is shown. The menu shortcuts still
>> use ^/⌥ (control) instead of ⌘ (command) for the modifier keys, etc. In
>> fact, I have not changed a single line of code yet. That would be
>> necessary to give it a more native feel. But at least it's a start.
>>
>> Regards,
>> Freek
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term contracts
>> Personal 24x7 support from experience hosting pros just a phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

p.s. the screenshot looks great.  I encourage you to continue working on it,
especially if it can be committed to the current code and doesn't cause
conflicts on Windows or Linux.

--
Chris

Please consider the environment before printing this e-mail.

On Thu, Jan 28, 2010 at 4:09 PM, Freek Dijkstra <sf_...@ma...>wrote:

> Freek Dijkstra wrote:
> > Out of curiousity, are there other Rails users who use Mac OS X, [..]
>
> That's more people than I anticipated. Is there interest in making the
> GUI a bit more native?
>
> I just gave it a shot. Here is a screenshot:
> http://www.macfreek.nl/temp/MacRails.png
>
> And here is the download:
> http://www.macfreek.nl/temp/MacRails-1.1.2.zip
> (Insert obligatory warning about the risk of executing programs you
> download from the web, especially if they are advertised by someone
> called Freek ;) )
>
> It is possible to build this Mac automatically (even on Linux or
> Windows), I'll post the patch for build.xml in a separate mail.
>
> Be aware that this is a very, very basic attempt. Yes, the menu bar is
> there, but somehow, it is only working if the Status Window is in the
> foreground, not when the Map Windows is shown. The menu shortcuts still
> use ^/⌥ (control) instead of ⌘ (command) for the modifier keys, etc. In
> fact, I have not changed a single line of code yet. That would be
> necessary to give it a more native feel. But at least it's a start.
>
> Regards,
> Freek
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

On Thu, Jan 28, 2010 at 4:15 PM, Chris Shaffer <chr...@gm...> wrote:
> p.s. the screenshot looks great.  I encourage you to continue working on it,
> especially if it can be committed to the current code and doesn't cause
> conflicts on Windows or Linux.
>
> --
> Chris
>

That's the nature of Java.  Write once, debug everywhere!  :-D

---Brett.

Freek Dijkstra wrote:

> It is possible to build this Mac automatically (even on Linux or
> Windows), I'll post the patch for build.xml in a separate mail.

See attachement.

In addition, these new files should be installed:
 tiles/logo.icns
 tiles/logo.png
Also, see attachment.

And finally:
 lib/jarbundler-2.1.0
Which can be downloaded from http://informagen.com/JarBundler/

I did not know what correct locations for each of these files are. Feel
free to change the location. I picked:
 tiles/ for program icons (not quite right, I know)
 lib/ for compile-time libraries  (also not quite right)
 MacRails-${version}/ for the resulting application (pick something)

Regards,
Freek

Nice work Freek.  Classic name for a hacker too ;-).  -Chris

The tiles directory is specifically for the images of hex tiles. Let's
create a new path for the logos. Calling it either 'images' or 'logos'
is fine by me.

The correct location for the jarbundler is in the same lib directories
as the Log4j and Batik libraries. It looks like you did that
correctly.

---Brett.

On Thu, Jan 28, 2010 at 4:21 PM, Freek Dijkstra <sf_...@ma...> wrote:
> Freek Dijkstra wrote:
>
>> It is possible to build this Mac automatically (even on Linux or
>> Windows), I'll post the patch for build.xml in a separate mail.
>
> See attachement.
>
> In addition, these new files should be installed:
>  tiles/logo.icns
>  tiles/logo.png
> Also, see attachment.
>
> And finally:
>  lib/jarbundler-2.1.0
> Which can be downloaded from http://informagen.com/JarBundler/
>
> I did not know what correct locations for each of these files are. Feel
> free to change the location. I picked:
>  tiles/ for program icons (not quite right, I know)
>  lib/ for compile-time libraries  (also not quite right)
>  MacRails-${version}/ for the resulting application (pick something)
>
> Regards,
> Freek
>
> ? lib/jarbundler-2.1.0
> ? tiles/logo.icns
> ? tiles/logo.png
> Index: build.xml
> ===================================================================
> RCS file: /cvsroot/rails/18xx/build.xml,v
> retrieving revision 1.8
> diff -r1.8 build.xml
> 12a13,15
>>       <taskdef name="jarbundler"
>>               classpath="lib/jarbundler-2.1.0/jarbundler-2.1.0.jar"
>>               classname="net.sourceforge.jarbundler.JarBundler" />
> 43c46,60
> <     <target description="copy Eclipse compiler jars to ant lib directory" name="init-eclipse-compiler">
> ---
>>       <target depends="build-release" name="build-mac">
>>               <mkdir dir="MacRails-${version}" />
>>               <jarbundler dir="MacRails-${version}"
>>                       name="Rails"
>>                       mainclass="rails.util.RunGame"
>>                       icon="tiles/logo.icns"
>>                       version="${version}">
>>                       <jarfileset dir="rails-${version}">
>>                               <include name="rails-${version}.jar"/>
>>                               <include name="lib/**"/>
>>                       </jarfileset>
>>                       <javaproperty name="apple.laf.useScreenMenuBar" value="true"/>
>>               </jarbundler>
>>       </target>
>>      <target description="copy Eclipse compiler jars to ant lib directory" name="init-eclipse-compiler">
> 101c118
> <     <target name="RunGame">
> ---
>>    <target name="RunGame">
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

brett lentz wrote:

> The tiles directory is specifically for the images of hex tiles. Let's
> create a new path for the logos. Calling it either 'images' or 'logos'
> is fine by me.

'images' it is.

> The correct location for the jarbundler is in the same lib directories
> as the Log4j and Batik libraries. It looks like you did that
> correctly.

I'm not sure about this. This means that it will end up in the final lib
folder of releases as well, even though that is not necessary:
jarbundler is only necessary during the build of the mac application,
not during it's execution. It would unnecessarily increase the size of
the application.

I am confused by build.xml (which builds the current jar file).

Apparently, the build sequence is as follows:
* clean build directories (classes, jar)
* create a classes and a build ("rails-$version") folder
* copy all(!) files, except .java files from root to classes folder
  (including log, README, tiles, lib)
* compile all .java sources in root, and put the classes in the
  classes folder.
* copy all files, except log, lib from classes to jar folder
* copy doc, lib from root to build folder
* combine all files in jar folder, and and create the .jar file
  in the build folder.

Two questions on the build:
* Why are files copied from root to classes?
* Why does the .jar include all files by default? This seems unnecessary
to me. For example, the jar contains scripts like tiles/CombineTiles.pl,
even though those are not needed during the game play.

Two more questions:
One adverted consequence about the inclusion of jarbundler was that the
sources, which came with jarbundler where also compiled, copied to
classes, and finally included in the rails.jar file (in
lib/jarbundler-2.1.0/src). I kind of doubt that is intended.
Should we fix this by only compiling sources in rails/ or test/ during
the build-process? Or by making sure there are no other source files?

Last -- what would be the preferred output folder for the mac
application? I know choose MacRails-1.1.2. Do you have better suggestions?

Regards,
Freek

On Thu, Jan 28, 2010 at 6:33 PM, Freek Dijkstra <sf_...@ma...> wrote:
>> The correct location for the jarbundler is in the same lib directories
>> as the Log4j and Batik libraries. It looks like you did that
>> correctly.
>
> I'm not sure about this. This means that it will end up in the final lib
> folder of releases as well, even though that is not necessary:
> jarbundler is only necessary during the build of the mac application,
> not during it's execution. It would unnecessarily increase the size of
> the application.

So, perhaps lib needs to be divided into build dependencies, and
run-time dependencies?

> I am confused by build.xml (which builds the current jar file).
>
> Apparently, the build sequence is as follows:
> * clean build directories (classes, jar)
> * create a classes and a build ("rails-$version") folder
> * copy all(!) files, except .java files from root to classes folder
>  (including log, README, tiles, lib)
> * compile all .java sources in root, and put the classes in the
>  classes folder.
> * copy all files, except log, lib from classes to jar folder
> * copy doc, lib from root to build folder
> * combine all files in jar folder, and and create the .jar file
>  in the build folder.
>
> Two questions on the build:
> * Why are files copied from root to classes?

Eclipse uses the classes directory to access a compiled version of
every .java file, so you can run the app from within Eclipse.

The build.xml is attempting to assure a clean build environment, so it
deletes the classes directory out from under Eclipse. That means that
we need to replace the classes directory, or Eclipse won't realize
that it's build environment is missing until you go to run the
application.

> * Why does the .jar include all files by default? This seems unnecessary
> to me. For example, the jar contains scripts like tiles/CombineTiles.pl,
> even though those are not needed during the game play.
>

It does that because I'm still new to using Ant, and haven't properly
documented everything to exclude from the jar.

Also, CombineTiles.pl shouldn't be in the tiles directory. It's not a
tile. It should be in with the other utils, or maybe we need a new
location to store non-java scripts.

Feel free to fix one or both of these issues. :-)

>
> Two more questions:
> One adverted consequence about the inclusion of jarbundler was that the
> sources, which came with jarbundler where also compiled, copied to
> classes, and finally included in the rails.jar file (in
> lib/jarbundler-2.1.0/src). I kind of doubt that is intended.
> Should we fix this by only compiling sources in rails/ or test/ during
> the build-process? Or by making sure there are no other source files?

Do we really need the jarbundler source copied into our tree?   I'd
prefer to just include the .jar, if we're not planning on patching the
source.

> Last -- what would be the preferred output folder for the mac
> application? I know choose MacRails-1.1.2. Do you have better suggestions?

We should test the jar on non-Mac platforms, and compare the UI.  If
it doesn't change the user experience for other OSes, I see no reason
to have a separate package. We can just bundle it in with the main
jar.

If it's too different or breaks something, then let's use
rails-<platform>-<version>.

> Regards,
> Freek
>

---Brett

It does that because I'm still new to using Ant, and haven't properly
documented everything to exclude from the jar.

Also, CombineTiles.pl shouldn't be in the tiles directory. It's not a
tile. It should be in with the other utils, or maybe we need a new
location to store non-java scripts.

Feel free to fix one or both of these issues. :-)

------

[EV] Yes, I think we need a separate top-level tools directory.

There is a lot more stuff in my tiles directory that I have committed
to CVS, because that's the place where I fiddle with tiles.
I have included these Perl scripts because I thought these might
be of interest to other people.

Erik.

brett lentz wrote:

> So, perhaps lib needs to be divided into build dependencies, and
> run-time dependencies?

I would suggest that.

> [CombineTiles.pl] should be in with the other utils, or maybe we need a new
> location to store non-java scripts.

I like Erik's suggestion for a "tools" directory. It could contain both
the perl tile-build scripts as well as the jarbuilder library. Both are
build scripts. Perhaps tools/lib and tools/tiles or tools/perl.

We can decide later what to with run-time scripts such as the Ruby mail
scripts from Chris' fellow players should also go in here.

> Do we really need the jarbundler source copied into our tree?   I'd
> prefer to just include the .jar, if we're not planning on patching the
> source.

I agree. My working copy contains the jar, license and doc only.

It could be argues to completely leave it out of the repository, but I
argue that it is useful for automated builds (perhaps one day we'll see
nightly builds...)

> Eclipse uses the classes directory to access a compiled version of
> every .java file, so you can run the app from within Eclipse.

My apologies for these (surely mundane) questions. I'm a rookie in
Eclipse (It keeps gives me a Way-Too-Many-Features-Overflow-Errors).

So if I understand correctly, Eclipse does not run the rails-1.1.2.jar
file, but runs the class files in the classes directory instead. And for
that to work, it needs all the files in the classes directory.

Out of curiousity: Does Eclipse actually use the build.xml at all? Or
does it do it's own thing and is build.xml an attempt to replicate this
behaviour?

> Feel free to fix one or both of these issues. :-)

I will do so, but still try to understand what exactly is going on
beyond the scenes.

>> Last -- what would be the preferred output folder for the mac
>> application? I know choose MacRails-1.1.2. Do you have better suggestions?
> 
> We should test the jar on non-Mac platforms, and compare the UI.  If
> it doesn't change the user experience for other OSes, I see no reason
> to have a separate package. We can just bundle it in with the main
> jar.

For clarity: the jar file is exactly the same. The only reason for a
separate directory is not to polute the current rails-<version> folder
with .app and .exe files.

What the jarbuilder does is create the following file structure:

rails-mac-<version>/
   Rails.app  (which includes the lib and jar files)
   README
   LICENSE

Similarly, a Windows builder will create something like:

rails-win-<version>/
   Rails.exe  (which includes the lib and jar files)
   README
   LICENSE

And a platform independent looks like:

rails-<version>/
   lib/
   rails-<version>.jar
   README
   LICENSE

In all cases, the .jar is the same.

Thinking about it, the *build* is the same: what is different is the
*packaging*. Some Makefiles distinguish between "make" and "make dist".
  Perhaps splitting this functionality is a bit overkill for now.

Regards,
Freek

On Fri, Jan 29, 2010 at 2:01 PM, Freek Dijkstra <sf_...@ma...> wrote:
> brett lentz wrote:
>
>> So, perhaps lib needs to be divided into build dependencies, and
>> run-time dependencies?
>
> I would suggest that.
>
>> [CombineTiles.pl] should be in with the other utils, or maybe we need a new
>> location to store non-java scripts.
>
> I like Erik's suggestion for a "tools" directory. It could contain both
> the perl tile-build scripts as well as the jarbuilder library. Both are
> build scripts. Perhaps tools/lib and tools/tiles or tools/perl.
>

I like this. Let's use it.

> We can decide later what to with run-time scripts such as the Ruby mail
> scripts from Chris' fellow players should also go in here.
>
>
>> Do we really need the jarbundler source copied into our tree?   I'd
>> prefer to just include the .jar, if we're not planning on patching the
>> source.
>
> I agree. My working copy contains the jar, license and doc only.
>
> It could be argues to completely leave it out of the repository, but I
> argue that it is useful for automated builds (perhaps one day we'll see
> nightly builds...)

For now, let's continue the trend we've started with log4j and batik.
If we use it, it should be in CVS so that other users don't have to
hit other sites for our dependencies.

>
>> Eclipse uses the classes directory to access a compiled version of
>> every .java file, so you can run the app from within Eclipse.
>
> My apologies for these (surely mundane) questions. I'm a rookie in
> Eclipse (It keeps gives me a Way-Too-Many-Features-Overflow-Errors).
>
> So if I understand correctly, Eclipse does not run the rails-1.1.2.jar
> file, but runs the class files in the classes directory instead. And for
> that to work, it needs all the files in the classes directory.
>

It, at a minimum, needs all of the .class files in the classes
directory.  I'm unclear on whether it needs everything else. It might
be worth experimenting with this.

> Out of curiousity: Does Eclipse actually use the build.xml at all? Or
> does it do it's own thing and is build.xml an attempt to replicate this
> behaviour?
>

Support for ant build files in Eclipse is fairly recent, so I'm not
sure what all of the details on how it's used.

>
>> Feel free to fix one or both of these issues. :-)
>
> I will do so, but still try to understand what exactly is going on
> beyond the scenes.
>
>
>>> Last -- what would be the preferred output folder for the mac
>>> application? I know choose MacRails-1.1.2. Do you have better suggestions?
>>
>> We should test the jar on non-Mac platforms, and compare the UI.  If
>> it doesn't change the user experience for other OSes, I see no reason
>> to have a separate package. We can just bundle it in with the main
>> jar.
>
> For clarity: the jar file is exactly the same. The only reason for a
> separate directory is not to polute the current rails-<version> folder
> with .app and .exe files.
>
> What the jarbuilder does is create the following file structure:
>
> rails-mac-<version>/
>   Rails.app  (which includes the lib and jar files)
>   README
>   LICENSE
>
> Similarly, a Windows builder will create something like:
>
> rails-win-<version>/
>   Rails.exe  (which includes the lib and jar files)
>   README
>   LICENSE
>
> And a platform independent looks like:
>
> rails-<version>/
>   lib/
>   rails-<version>.jar
>   README
>   LICENSE
>
> In all cases, the .jar is the same.
>
> Thinking about it, the *build* is the same: what is different is the
> *packaging*. Some Makefiles distinguish between "make" and "make dist".
>  Perhaps splitting this functionality is a bit overkill for now.

It makes sense to add these OS-specific build targets into the
build.xml, and let the build file handle creating each package.  The
more we can automate, the easier it is to support frequent builds.

If we're going to support it, this seems like a way that makes the most sense.

>
> Regards,
> Freek
>

---Brett.

>> Eclipse uses the classes directory to access a compiled version of
>> every .java file, so you can run the app from within Eclipse.
>
> My apologies for these (surely mundane) questions. I'm a rookie in
> Eclipse (It keeps gives me a Way-Too-Many-Features-Overflow-Errors).
>
> So if I understand correctly, Eclipse does not run the rails-1.1.2.jar
> file, but runs the class files in the classes directory instead. And for
> that to work, it needs all the files in the classes directory.
>

It, at a minimum, needs all of the .class files in the classes
directory.  I'm unclear on whether it needs everything else. It might
be worth experimenting with this.

[EV] Eclipse can run from the jar, but if it has classes in its 
classpath, it prefers to use these  (which is logical, because 
Eclipse is used for developing, and the classes must be open
in the wild before they can be packaged).

> Out of curiousity: Does Eclipse actually use the build.xml at all? Or
> does it do it's own thing and is build.xml an attempt to replicate this
> behaviour?
>

Support for ant build files in Eclipse is fairly recent, so I'm not
sure what all of the details on how it's used.

[EV] I suppose you can run a build script from Eclipse, 
but it's a manual action. I never do it.
Building is not well-integrated into Eclipse. Same with Ant scripts,
which I use a lot but not for building. I always run Rails from Eclipse
itself (except when trying from an old jar for problem solving).

[EV] Eclipse also has a separate Jar build function, but that's different.

Erik.