incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hannes Schmidt <han...@eyealike.com>
Subject Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
Date Fri, 09 Apr 2010 00:42:21 GMT
In a nutshell, I disagree with the decision to resolve

https://issues.apache.org/jira/browse/CASSANDRA-697

as Won't Fix. Here's why:

One of the central motivations behind Maven was to once and for all get rid
of binary dependencies in source repositories. You, the Cassandra committers
operating under the Apache umbrella should have no difficulty getting those
lib/*.jar dependencies into the official repository. It shouldn't take more
than half an hour to "mvn deploy" a handful of jars. On that note, it should
be a no-brainer to actually deploy the *Apache* Cassandra JAR to the
*Apache* Maven repository.

Sorry for the rant but taking shortcuts like this forces every Maven user
down the stream to either do the work for you, e.g to deploy the Cassandra
JAR and its dependencies to their local repository or take the very same
shortcut. The Hector client, for example, has a dependency on the Thrift and
Cassandra JARs and it takes the shortcut of having both JARs in the
repository. If I want to use the client in my own Maven-built project, I
can't do so without manually deploying those two JARs along with the Hector
JAR to my local repository.

To add fuel to the fire, I don't think that there is a real need for
two coexisting build systems for Cassandra (I'm speaking of Ant/Ivy and
Maven) but even if you decide to go with Ant/Ivy, the resulting artifacts
should all be accessible in a public Maven repository. This is pretty much a
convention for any OS project of Cassandra's reach and maturity.

-- Hannes

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message