2008/11/20 Rafael Schloming <[EMAIL PROTECTED]>: > Martin Ritchie wrote: >> >> I'd agree here. a zip of the build directory is not a binary release. > > One of the original design principles of the build system was that the build > directory should be as close as is possible to the binary release. The idea > being that the closer our development environment is to a released > environment, the fewer surprises there will be when we release, and the less > disparity there will be between developer docs and user docs. > > This principle may have been lost a bit in some of the subsequent > modifications since the inception of the build system, but I still think > it's a good one. So while currently a zip of the build directory might make > a sub-optimal binary release, IMHO it *should* be the case that it makes a > perfectly reasonable binary release. Certainly there should be a very good > reason for each piece of extra scripty magic that you need to run to convert > the build dir to a release dir, since each one of these is a potential > pitfall for our users. (I am yet to be convinced that we currently need > *any* scripty magic.)
Having the build system generate a directory structure that is our aim to release is fine however that would need to be documented as a goal so that new people to the project know that. The QMan war generation is a prime example as it uses the build directory as a scratch space to generate the release war. Something that the review process could have picked up if it was more widely known that the build directory was our release artefact. I don't think we ever quite got to the goal of having the build directory being the ideal binary distribution. Looking at the contents of build after an 'ant clean build' results in a large number of files that we do not want to ship. The build target sets up the build directory for running the tests as it generates the results hierarchy and and the data directory. These are not recent changes as far as I am aware. If our plan is to have 'ant clean build' produce a build directory that we can zip up for a release then we are going to have to work on that and document it so we are don't put files in the the build directory that we would not want to be distributed. I'm still firmly of the belief that it would be normal for each module to produce a release artefact and it would only be common as the exception that doesn't, unless we standardise a low level api. Management may also be an exception as it generates multiple artefacts one for each of its sub modules. As an end user I can see the advantage of downloading a single binary package however I don't then want to have to pick through over 60 jar files to find the require dependencies for my client code. I would much prefer to have individual packages so that we can then patch and release changes as required. If there is a critical bug in the client code we shouldn't have to do a full Qpid release. >> If we are interested in doing separate broker and client packages then >> the 'ant release-bin' currently generates a useful package. > > Along the same lines as above, IMHO generating separate sub-packages for > distinct pieces of the project should be as simple as identifying the > appropriate subset of files underneath build. The build system already knows the majority of the subset why should we have to go and identify the files again to be included in a module build? Perhaps I'm just not seeing what you are. If you have a proposal of how this would look then perhaps you can sway my thoughts. Regards Martin > --Rafael > -- Martin Ritchie
