incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hannes Schmidt <han...@eyealike.com>
Subject Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
Date Fri, 09 Apr 2010 17:42:54 GMT
On Fri, Apr 9, 2010 at 6:21 AM, Gary Dusbabek <gdusbabek@gmail.com> wrote:

> Hannes,
>
> There is no way to sugar coat this, so I'll just say it:  I'm a mvn
> hater, so I have to disagree with you.  The basis of my hatred is that
> I've used mvn before (as part of my job) and found it extremely
> encumbering as a developer.
>

I could say that I "love" Maven but I found that when people resort to
strong emotions towards or against mere tools, the discussion quickly gets
unproductive. Productivity is what I care about and that's why I use Maven.


>
> I will try to put my prejudices aside as I make a few points though.
>

Good.


>
> On Thu, Apr 8, 2010 at 19:42, Hannes Schmidt <hannes@eyealike.com> 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.
> >
>
> Cassandra is a community of volunteers.  If someone is willing to take
> that half-hour and make Cassandra a mvn-friendly place and maintain it
> whilst moving forward, I say let it happen.  Make it easy for us to
> package a release and push it to a repo.
>

Ahh, the standard OS defense. ;-) I would deploy these jars to the public
Maven repo in a second, if I had the creds to do so.


>
> Nobody has stepped up to do this though.  We had a pom in trunk for
> quite a while.  None of the developers used it, and therefore had no
> motivation to maintain it.
>

None of them used it probably because it's hidden the contrib folder and
they already had a working Ant build. You can't seriously maintain two build
systems for a project. It doesn't make sense and that's why nobody adopted
the alternative build system.


>
> > 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.
>
> I disagree that every project should do things the mvn way for the
> sake of making things easier for mvn users.
>

No, but maybe every Apache project should?


>
> >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.
>
> Because packaging dependencies and bundling a project is work.  I
> can't speak for rantav, but I think he's being pragmatic and not just
> taking a shortcut.
>

Sure, I have been pragmatic a lot in my career. Some of my pragmatism bit me
or others down the line. It's called taking technical dept.


>
> > 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.
> >
>
> I've been there, and I feel your pain.  Pushing three jars to your
> local repo isn't a big deal though.  If you're working on a team,
> deploying three more jars on your nexus repo isn't too hard either.
>
>
Why don't you do it then? If you did it, you'd save many others from having
to do it. This isn't a you-vs-me kinda problem. It's a you-vs-many problem.


> Gary.
>
> > 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
> >
>

If I had more trust in the team's motivation to embrace a what I believe is
a truly better build tool than Ant/Ivy I would spend the time of migrating
Cassandra to Maven on an experimental branch and let you guys take a look.
But for this to work and be true evidence of Maven's superiority, the jars
in libs/ need to go away, hence this thread.

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