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. > 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. -- Russel. ==================================================== Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
