Martin Ritchie wrote:
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 think had I been more prescient I would have documented this carefully
from the beginning, but to be honest I didn't realize at first exactly
why I did it that way. It just felt *simple* and *right*. It was only
later that I realized there was some merit beyond my own prejudices.
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.
IIRC there were initially a small number of scratch directories under
build that were excluded when generating the tarball, e.g. the classes
directories. It might be better to gather these under one scratch dir to
simplify the exception.
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.
Agreed.
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.
I think what constitutes a release artifact should actually be defined
external to the build system proper, and the build scripts shouldn't be
filled with special case logic to cope with the idiosyncrasies of each
sub-module. This may put some constraints on what the release tarball
looks like, e.g. any distinct components should be easy to pick out of
the full release structure, but this is IMHO a fairly mild and
reasonable constraint.
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.
I don't think as an Apache project we would ever want to do separate
releases of particular sub-component, but I can see how it would be
useful for those commercial entities providing support for Qpid to be
able to do that sort of thing. So for me, this becomes a nice to have
sort of thing, but not really a priority for an Apache 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?
I'm not suggesting we should duplicate anything. I'm suggesting the
structure of a full release should make it easy to pick out how the
different artifacts relate to each other.
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.
I wouldn't worry about how it works so much. The first step is to figure
out what a release should look like, i.e. what downloads there are, how
each one is structured, and how they relate to each other. Once that is
settled we can figure out how to make it work. I think going straight
into hacking the build system will only result in a release structure
that is too intimately tied into the details of the build system.
--Rafael
