incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hannes Schmidt <>
Subject Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
Date Fri, 09 Apr 2010 04:15:28 GMT
On Thu, Apr 8, 2010 at 7:54 PM, Eric Evans <> wrote:

> On Thu, 2010-04-08 at 17:42 -0700, Hannes Schmidt wrote:
> > In a nutshell, I disagree with the decision to resolve
> >
> >
> >
> > 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
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

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