On Mon, 2002-03-18 at 23:41, Craig R. McClanahan wrote: > > The projects that inherit their build philosophy from Turbine definitely > like lib.repo, because they tend to put all the dependency JAR files in > one place. > > The projects that inherit their build philosophy from Struts and Tomcat > definitely like base.path, because they assume that you have checked out > and built each of the dependent JARs, in a common base subdirectory.
Just as a point to mention, this is how most of the Turbine developers work. We generally check everything out we just have the additional step of placing each produced JAR in a shared directory before building. This process is now used in Maven, what Turbine is now using for all its builds and for producing the Turbine sites, and it uses this method but it could easily be made to accommodate other modes of developing. We're trying to encourage the use of a central repository of JARs. Having the one repository makes things like automatically downloading JARs easier for those who are interested in only developing or fixing the single package they are interested in. I'm only pointing out that we work in a similiar fashion in that we like to have everything checked out, that's generally how I work at any rate. I think that having a central repository of JARs would make a generalized continuous integration mechanism a little easier. Where a project is working against a known set of binaries and you're building every 5 minutes to find errors that have been introduced into a build. With a central repository of JARs this would work for any project. I'm also adjusting Maven to use a "dist" directory because I release all of Turbine family yesterday trying to use Maven and it was a bit cumbersome so I'm going to adopt the "dist" directory to try and make this easier. > (For > me, for example, that is /home/craigmcc/Jakarta, with a subdirectory under > it for each CVS repository I care about, and I maintain the results of > "ant dist" builds in each case for the code that I currently develop > against). > > The defaults from Digester have inherited the latter philosophy (because > of where the code came from), so base.path is a better name for > build.properties.sample in this case. > > NOTE: This isn't a value judgement on which philosophy is better -- both > are equally valid, but consistency within a particular philosophy is even > more important than choosing one or the other. Right, I think we have just evolved in different ways but I think a central store of JARs may be easier for people to work with and this doesn't prevent someone from creating these JARs on their own machines. We use this method in Turbine coupled with an automatic JAR downloading mechanism to help people who are not interested in building all the dependencies. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
