Les, I think you bring up some very good points. While I'll just toss it out as a nomination, Maven has done a lot of work dealing with these multiple related project issues. The reactor allows you to build a series of projects, and sorts out any interdependencies they have. It deals with a changing number of projects nicely. The multiproject plugin allows you to apply the same operation against n number of projects, and attempts to bring them into a single cohesive whole from a documentation stand point.
The avalon wrapper is built using Maven, and maven is called from the parent ant script that builds the rest of the extensions if you want to see an example. Since hibernate already has very well fleshed out website, the maven site building features may be less important, but the reporting might be nice to have. Maven would also automatically solve the desire to download versioned jars. This would help solve the mising dependencies. I also think that you could quite easily put together using the uberJar your "just binaries" jar that would be something that a casual user would be able to use. Something I would like to see is the ability to release various sub projects like the tools,avalon wrapper, hibern8ide, hibernate seperatly and version the dependencies between them. Right now, all of the tools more or less need to release together. And hibernate releases together. I would like to do a release of the avalon wrapper soon, but can't, or at least it is hard, because it is built with the rest of the hibernateExt. Also, dealing with each component seperately will make dependencies easier when hibernate 3.0 comes out, and the various components aren't upgraded in lockstep. I know builds can often devolve into religious arguments about tools, so I just wanted to toss this out. The main thing is to have an easier build! I am traveling for the rest of the week (going to Madrid, Spain!), but would be willing to help next week. Sincerely, Eric http://maven.apache.org/ http://maven.apache.org/reference/plugins/multiproject/index.html http://maven.apache.org/reference/plugins/uberjar/index.html > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Les > Hazlewood > Sent: Monday, August 25, 2003 5:15 PM > 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
