Les, Sounds interesting, but Java lib directories are getting ever more complex. Between the Jakarta set of tools and other little pieces that go into making a large framework tick - you can easily end up with version mismatches. $APP_HOMEs need consistent usage for them to work.
My opinion is that a release or a build should include all dependent jars that were used in the unit tests. Reliance on jars existing on a target machine is, IMHO, problematic. I manage deployments where we have about 40 dependent jars. New releases of dependencies can often break a large application, and it can take hours sometimes, even with unit tests to identify a "dependency behavioral problem" and make adjustments for it. Or did I misunderstand what you were trying to say? Anyway, bundling ALL dependencies that are not guaranteed to be present on the users' machines is really a must. How it's done is upto the project. Sandeep. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Les Hazlewood Sent: Monday, August 25, 2003 10:15 AM To: hibernate list Subject: [Hibernate] build structure Gents (and Ladies?), I had my first experience with the full Hibernate build this morning, including the build of the HibernateExt and Tools modules. I thought things were....well....yucky ;) I have a firm belief in leaving out jar files in a cvs repository, as that is not source code, and dependencies change frequently. IMHO, it is far better to use the $APPNAME_HOME approach when using dependencies, and having the ant script dynamically check environment variables to see if the required dependencies are installed on a system. If not, you could even have the script pull them from a common repository (e.g. Maven's Ibiblio repository). Also, a hierarchical build appraoch using a single CVS module would be much nicer. E.G. using a master build script that you act upon regularly. Then one could call "ant tools" or "ant extensions" or "ant core" to build the respective modules. Perhaps an "ant suite" target builds everything for a common distribution of all modules for the average every day user. I further believe the there should be a "binary only" distribution of Hibernate (including all of its tools) as a "Hibernate Suite" distribution that includes docs, api, etc, but without any source files, build scripts, or irregular build directories. This would be for the average every day Hibernate user who needs it on their system. Also, I don't think it is important to separate the tools classes from the Hibernate core classes, as they are probably more frequently used together than apart. (e.g. the CodeGenerator in the tools distribution, I would argue, is a core feature of Hibernate). The separation of the two sets causes more confusion then assistance, in my opinion. Of course, the Hibern8IDE, could be considered a seperate product, but could still be distributed in the Hibernate "Suite" version. Finally, it might be a good idea to have a hibernate.jar file that includes all compiled class files needed for hibernate to execute, except any dependencies. Dependency class files could be in a hibernate-dep.jar file. I'm not sure if this would be a useful approach, but it _is_ a big pain to have to look in 4 directories just to set up a hibernate classpath...($HIBERNATE_HOME, $HIBERNATE_HOME/lib, $HIBERNATE_TOOLS_HOME, $HIBERNATE_TOOLS_HOME/lib). Thoughts, comments, suggestions, hate mail? ;) Les P.S. If no one objects, I'd like to put together a hierarchical ant build sometime this weekend (family in town, so I can't do much until then) and show you what I'm talking about. ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
