On Thu, Apr 8, 2010 at 7:54 PM, Eric Evans <eev...@rackspace.com> wrote:
> On Thu, 2010-04-08 at 17:42 -0700, Hannes Schmidt wrote: > > 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. > > Are you suggesting that we push cassandra into the maven repo with > unsatisfiable dependencies? How will that satisfy your dependency on > cassandra? > No, if you deploy Cassandra you need to deploy the dependencies, too. If - you can't find the owner of the dependency or - they are unwilling to publish their artifacts - or it's too difficult for them to do so (it can be hard to get something in the public repos at times, but since you guys are at the source it shouldn't be a problem) you should deploy those artifacts yourself. In that case I would deploy them to groupId org.apache.cassandra.deps or something like that. If a Maven project depends on the Cassandra JAR, Maven will pull Cassandra's dependencies automatically. Maven's dependency mechanism is transitive. > > > 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. > > It might be reasonable to break out the bits of cassandra that are > useful to libraries like Hector, and put them into a separate jar which > doesn't rely on the problematic libs... except that Thrift is one of > those problematic libs (it isn't in a repo). :/ > Couldn't agree more, the client-specific stuff should be in a separate JAR. And if the Thrift owners refuse to deploy their stuff, you can always resort to deploying libthrift.jar yourself as mentioned above. > > > 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. > > Which reminds me, you might want to have a look at > https://issues.apache.org/jira/browse/CASSANDRA-850. > > Yep, that's related. My two cents: the Cassandra project should produce at least 5 artifacts: - the fat jar with all dependency class and resource files included and executable via "java -jar", - a slim jar for the server-side code, - a client jar and - for the latter two, accompanying -source.jar files with all sources incl. the ones generated by Thrift. > -- > Eric Evans > eev...@rackspace.com > >
