Hi Russel,
On Dec 10, 2008, at 10:57 AM, Russel Winder wrote:
Hans,
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.
I have always been in two minds over this issue.
On the one hand having all the dependencies locally means once you
have
downloaded Gradle there is nothing more needed. This is a nice safe
position that many prefer, and yet it takes inordinate amount of disc
space.
On the other hand making use of the Maven repository means that
dependencies are stored in the cache, be it Maven or Ivy. This means
once you have undertaken an action once with an Internet connection
and
an up repository, the situation is no different to the above. Except
that some people just don't like this way of doing things.
Personally I
prefer it.
What I would say though is that having a special target to download
all
the necessary dependencies would make things far easier. I haven't
done
this for Gant, but I think I should. It matters more for Gradle
though.
By being able to download Gradle and immediately run gradlew
downloadDependencies means that the situation is effectively the
same as
having the dependencies in the Gradle repository.
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.
Changing this requires that the gradlew script can download the binary
distribution for gradlew which is a highly complex endeavour requiring
extra tooling for the bootstrap.
Fortunately Gradle can do this already.
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:
I think separating the general dependencies and the gradlew
installation is probably a good thing in this discussion. For me the
argument for storing general dependencies in the Gradle repository is
very weak: for me it is a "no brainer" to handle this by download
from
the Maven repository. The case for gradlew is much more tricky.
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.
This would have the consequence that the build becomes dependent of
infrastructure set up. 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.
What do you think?
I think the point here is that you will have to declare and "end of
history" and start a new repository without the jars in. Only then
will
the DVCS repositories get small. As soon as any of the Subversion
history has the jars in then the DVCS repositories/branches will be
big.
So the trick here is I think to talk with Ben to copy the current
Subversion repository to gradle_old and allow it to remain available
but
read only and to start a new repository from scratch with the new
policy
in place.
Now is definitely an opportune moment since 0.5 has just gone out the
door so by undertaking a revision of the policy now and using it as
the
start point for 0.6 there is a suitable barrier to expectations.
That would be a good approach. I will talk with Ben if this is
something he would support.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
