And I can only agree that it would be cool not having jar's in CVS - but from a common respository instead....but hey - that is VERY limiting with regards to iblio since it does not have everything we need + it only includes the jars ....so where do i get docs, src etc. for it ;)
(yes - just adding jars to cvs does not help me in this - but using maven and/or iblio does not improve the situation)
So, if you can tell me how to have a more flexible structure (for big projects) then I would happily use Maven....until then - no way ;)
/max
Gavin King wrote:
In my opinion:
* splitting the tools out of the Hibernate core was the one of the best things we ever did - it keeps the download small enough and external dependencies under control (Hibernate was starting to look very bloated)
* Maven looked great until I actually tried to use it and realized it is the creation of either aliens or Satan
* I HATE not having compatible jar files in CVS - I have seen this make other projects almost impossible to build
:)
Gavin
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
------------------------------------------------------- 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
------------------------------------------------------- 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
