On 13 July 2011 00:47, Jonathan Ellis <jbel...@gmail.com> wrote: > On Sat, Jul 9, 2011 at 8:29 PM, Rick Shaw <wfs...@gmail.com> wrote: >> >> On Jul 7, 2011, at 10:53 AM, Eric Evans wrote: >> >>> On Wed, 2011-07-06 at 13:33 -0500, Jonathan Ellis wrote: >>>> - the git mirror won't pick up anything under drivers/ >>> >>> Has there been any effort made to have INFRA add it? > > Aaron asked, they said they only do standard svn trunk + branches + tags.
But I think what they mean is that you'd need to tweak things a little, e.g. svn mkdir http://svn.apache.org/repos/asf/cassandra/server svn mv http://svn.apache.org/repos/asf/cassandra/trunk http://svn.apache.org/repos/asf/cassandra/tags http://svn.apache.org/repos/asf/cassandra/branches http://svn.apache.org/repos/asf/cassandra/server/ svn mkdir http://svn.apache.org/repos/asf/cassandra/drivers/trunk svn mv http://svn.apache.org/repos/asf/cassandra/drivers/java http://svn.apache.org/repos/asf/cassandra/drivers/py http://svn.apache.org/repos/asf/cassandra/drivers/trunk/ and basically end up with at the http://svn.apache.org/repos/asf/cassandra/ a set of directories with trunk/tags/branches underneath. In fact I suspect you would not even have to move the main branches (which would be better for svn mergeinfo) as they should be able to retain the git repo for that as is and just by structuring the drivers directory with a trunk/tags/branches (and sure keep branches empty if you want) they could give you git://git.apache.org/cassandra-drivers.git for the drivers and git://git.apache.org/cassandra.git remains in place and as is for the core/server if they give you any hassle just point out that they do this already for mina, myfaces, maven, etc... and if it is a big issue you can always rename cassandra to massandra as they seem to do it for any project beinging with "m" ;-) > >>> What do you mean by "but not have multiple versions for 0.8 branch"? > > I mean it would live in trunk but only in trunk -- there would be no > branches/0.8/drivers or branches/1.0/drivers. > >> Can't we keep the /drivers code in the trunk and just have separate Ant >> tasks for building the driver parts independent of the tasks for for the >> server? > > Right, this feels ideal to me. Otherwise the "right" way to handle it > is to download a Cassandra stuff-the-driver-needs jar from the maven > repo. I will be providing a patch that will allow deploying -SNAPSHOTs to the apache snapshot repository once I get some releases off the decks at Maven, that will make life easier for the Hector guys etc (as they can follow trunk more easily, and push -SNAPSHOTs themselves to allow for easier user testing) but a side-effect is that it would make life easier if you went with this approach... and remember that the maven repo in this case does not even need to go off your machine as you can just install the core deps in your local repo by doing a build of core locally. > I'd rather just have {cassandra} and {driver} build targets > personally, from the same tree, rather than introducing this > intermediate dependency. It does bring up versioning... the tag for drivers releases will include cassandra stuff too... I have the feeling that you cannot have your cake and eat it too > >> Another thought would be to keep it in the separate tree as it is now, and >> dumb down the driver build to just build the JAR artifacts (binary, source, >> and javadoc). and do all testing and integration work in the server-side >> trunk by using just the Driver jar as a dependency for the tests in the >> server tree? > > Then you have the reverse problem, that running the test suite > requires this other checkout to be around somewhere. But the driver jar is supposed to be more stable, and have a much slower release cadence. I see much less of an issue pulling the driver jar from the (local/remote) maven repo than pulling the core stuff. I would see this option as being closer to the way you guys seem to want to work... But I will raise this one question.... The tension seems to be between whether to re-release a drivers jar with every core release, or have it with its own release cadence. To my mind, from the Maven Pom point-of-view as long as the drivers depend on core classes (and that includes thrift) it needs to at least match the release cadence of core releases (i.e. you would need one release for each release of core, and if it needs its own bug-fixes they would be extra releases) The major pain for releasing the drivers jar is that you have to test it... building it is no big shakes but testing is where the effort lies. Now the testing effort has to happen anyway at the main core release cadence, because even if you think you don't need to rebuild drivers for the core 0.8.2 release, you do need to test that the drivers jar you tested against 0.8.1 still works [or at least do some investigation to say that the changes cannot affect it working... chaos butterflies will still want testing though*] and that is ignoring the Maven Pom issue§ So here is the question: Does it really make sense to release the driver jar independently? Yes you save on building that one jar, but that is just a 2-3s increase in build time, and you cannot save on your testing effort... the only thing that it might buy is a saving on building effort for users of cassandra** * and your testing should be automated and run every time so a manual impact assessment will always be more work than just running the tests § which I am trying to keep out of this, as you guys seem to ignore what I say when ever Maven comes up ;-) ** in that if they are willing to trust the Cassandra testing effort, they could just upgrade the server and not upgrade their application to include the matching driver.jar... but what company, that cares about testing, is going to be happy with that story... none that I know... upgrading the DB server... well you will want to retest your application against the new one won't you... and testing effort should always be greater than building effort (or else you either have no tests or a crappy build) so it would be no skin off your nose including an updated drivers jar. > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com >
