From: brett l. <wak...@gm...> - 2010-01-29 22:16:56
|
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. |