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 Sat, 10 Apr 2010 14:10:40 GMT
On Fri, Apr 9, 2010 at 12:24 PM, Gary Dusbabek <gdusbabek@gmail.com> wrote:

> On Fri, Apr 9, 2010 at 12:42, Hannes Schmidt <hannes@eyealike.com> wrote:
> > On Fri, Apr 9, 2010 at 6:21 AM, Gary Dusbabek <gdusbabek@gmail.com>
> wrote:
> >>
> >>
> >> 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.
> >
>
> What we really need is someone to own this by being willing to support
> mvn users, respond to the jira tickets they generate, and send patches
> to the committers.
>
> >>
> >> 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.
> >
>
> It was in the root of trunk.
>
> >>
> >> > 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?
> >
>
> Why?  "To make things easier for mvn users" isn't enough of an
> argument to convince me.
>

I can't really help you with that. Maven users make up a considerable
segment of your potential user base. If making life easier for them doesn't
motivate you, I am not sure what does. It surely isn't a sense for the
community.


>
> >>
> >> > 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.
> >
>
> I don't wish to be the one to support it.  Past experience has turned
> me off to mvn.  I have a me-vs-mvn 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.
>
> I think that's an unfair judgment.  Seriously--what's stopping you
> sending in a patch that updates the pom and leaves us with artifacts
> that can be pushed to a mvn repo?  Wouldn't that satisfy your needs.
>
> Gary.
>

Reviving the currently abandoned pom.xml, waiting for the committers to push
the project artifact and its dependencies in libs/ to a Maven repository
would indeed satisfy my needs. But given the evidence for the project's
"hate" against Maven I would be pretty naive to be devoting any significant
amount of time to this, wouldn't I? It's the other way around. You had a
beautifully working POM, a lot of work had gone into it but the team
abandoned it, for example by closing 697 as won't fix.

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