Hans Dockter wrote:
Hi,
right now we store our external dependencies in svn. This provided a
nice out of the box experience when building Gradle and we don't have
to care about other repositories and there downtimes.
What we also store in svn is a complete Gradle binary distribution
capable of building Gradle, which is used by the wrapper. This is
important for people who want to build the latest Gradle. Often the
latest Gradle can't be build with a release as we use new features
from trunk. With the wrapper you don't care about this and can easily
build Gradle independent of whether you have Gradle installed at all,
or whether you have installed a Gradle version incapable of building
the latest Gradle. The reason we put the gradle binary dist used by
the wrapper in svn, is out of the box experience and build
reproducibility. You can check out in two years current trunk and you
can easily build it.
But there is a downside of storing all the binaries in svn. Our
repository size has grown to 130 MB. This is partly owed to a fixed
bug, which did force us to provide a new binary wrapper distribution
even after doing only some minor changes to the API. But even without
this bug the size of the repository would be pretty big. This is not a
big problem if you use only svn. But as soon as you start using DVCS
tools like bazaar this is a real pain, as you do branches with the
full history. I'm very keen to start using Bazaar for contributions
very soon. I'm very sure that I will use it for my own development
(Codehaus SVN will remain the master). Therefore I'm wondering if we
should do two things:
1.) Use repositories for storing our external dependencies
2.) Store the binary distribution used by the wrapper not in svn but
in the codehaus snapshot repository.
I think we should. This is a pretty common pattern for builds -
certainly for the ones I work with. Switching would force us to deal
with and fix some of the associated problems.
This would have the consequence that the build becomes dependent of
infrastructure set up.
I think there are things we can do to minimise this. For example:
- adding an offline mode
- a task to fetch all the build dependencies (including plugins, bits of
gradle itself, and all the transitive dependencies)
- a task/plugin which builds a self contained buildable source
distribution from the source + the above
If for example the URL of the codehaus snapshot repository will
change, a build of a past revision of Gradle won't be possible out of
the box. You have to modify the settings to make it work. But I can
live with that, as building old versions of Gradle is probably not
such a major use case and will always be possible, even if the rather
stable infrastructure set up will change.
If we decide to go for this approach, what do we do with the binaries
of the past which make a checkout so big? I was talking with Tom
Eyckmans about this here at Devoxx and he said you can make a svn dump
and filter them out. This again raises the issues of builds of past
revisions. This would still be possible then but not out of the box.
Yet I would like to throw out the binaries of our svn history.
I think we could start again with a new repository.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
