Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Hannes Schmidt <ha...@eyealike.com>]

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

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Hannes Schmidt <ha...@eyealike.com>]

On Thu, Apr 8, 2010 at 7:54 PM, Eric Evans <ee...@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
> eevans@rackspace.com
>
>

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Eric Evans <ee...@rackspace.com>]

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?

> 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). :/

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

-- 
Eric Evans
eevans@rackspace.com

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Bill de hOra <bi...@dehora.net>]

Your sense of righteousness would be better directed to code. File a 
patch, be useful; if this community wants maven they'll follow you.

Bill

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

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Hannes Schmidt <ha...@eyealike.com>]

On Sat, Apr 10, 2010 at 4:50 PM, Tatu Saloranta <ts...@gmail.com>wrote:

> On Sat, Apr 10, 2010 at 7:10 AM, Hannes Schmidt <ha...@eyealike.com>
> wrote:
> > On Fri, Apr 9, 2010 at 12:24 PM, Gary Dusbabek <gd...@gmail.com>
> wrote:
> ...
> >> 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.
>
> How about stopping asking for others do the work, and doing it
> yourself, if YOU care so much?
> This approach (of actually DOING something) has been suggested
> multiple times: and next comments is likely to be along lines of "just
> fuck off".
>

Tatu, I can't do the work. If I could, I already would have done it. And
it's not because I don't have the time. Only the project owners can deploy
the jars to a public Maven repository. This is minimal amount of work that
would be necessary simply to save the work another contributor had already
done.

I made the mistake of mingling two issues: A) moving the build for the trunk
to Maven (which is clearly not going to happen) and B) saving the efforts
that went into the Maven POM which was contributed for 0.5. The latter
should have been the primary focus of the discussion and I am responsible
for distracting from it.


> And please do not talk as if you represented significant segment of
> unhappy users -- if there are others, they are quite capable of
> speaking up to support your request.
>

Given the hostility of your response they might be afraid to speak up? But
seriously, most of them probably don't have the time to research this
problem or "whine" in here. They just deploy the respective artifacts to
their local repo and get on with life which is probably what I should have
done in the first place. Unfortunately, this would only work for 0.5,
though, not for the trunk because the POM there is not functional. This is
where A) comes in and I do realize that I should be the one to fix the POM
and ask for the artifacts to be deployed. But this is exactly the same kind
of work that went into the 0.5 POM. And did the committers live up to their
part?

Assuming that the team does not want to move to Maven, there are two
alternatives to A): Either the Ant/Ivy build could deploy the artifacts to a
Maven repository or someone could generate stub POMs for Cassandra. I don't
think stubs are gonna make it into a public repo so these would have to be
published somewhere else.


>
> Pardon my french, but this seems to fall to the repugnant category of
> "not enough time to help, enough time to whine".
>

Hmm, yeah, I really don't appreciate your tone.


> -+ Tatu +-
>
> ps. I'm not part of project team, and above opinion is my personal
> one. Just so there's no misunderstanding.
>

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Tatu Saloranta <ts...@gmail.com>]

On Sat, Apr 10, 2010 at 7:10 AM, Hannes Schmidt <ha...@eyealike.com> wrote:
> On Fri, Apr 9, 2010 at 12:24 PM, Gary Dusbabek <gd...@gmail.com> wrote:
...
>> 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.

How about stopping asking for others do the work, and doing it
yourself, if YOU care so much?
This approach (of actually DOING something) has been suggested
multiple times: and next comments is likely to be along lines of "just
fuck off".
And please do not talk as if you represented significant segment of
unhappy users -- if there are others, they are quite capable of
speaking up to support your request.

Pardon my french, but this seems to fall to the repugnant category of
"not enough time to help, enough time to whine".

-+ Tatu +-

ps. I'm not part of project team, and above opinion is my personal
one. Just so there's no misunderstanding.

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Hannes Schmidt <ha...@eyealike.com>]

On Fri, Apr 9, 2010 at 12:24 PM, Gary Dusbabek <gd...@gmail.com> wrote:

> On Fri, Apr 9, 2010 at 12:42, Hannes Schmidt <ha...@eyealike.com> wrote:
> > On Fri, Apr 9, 2010 at 6:21 AM, Gary Dusbabek <gd...@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.

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Gary Dusbabek <gd...@gmail.com>]

On Fri, Apr 9, 2010 at 12:42, Hannes Schmidt <ha...@eyealike.com> wrote:
> On Fri, Apr 9, 2010 at 6:21 AM, Gary Dusbabek <gd...@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.

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

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Hannes Schmidt <ha...@eyealike.com>]

On Fri, Apr 9, 2010 at 6:21 AM, Gary Dusbabek <gd...@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 <ha...@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.

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Hannes Schmidt <ha...@eyealike.com>]

On Fri, Apr 9, 2010 at 10:41 AM, Jonathan Ellis <jb...@gmail.com> wrote:

> On Fri, Apr 9, 2010 at 12:11 PM, Hannes Schmidt <ha...@eyealike.com>
> wrote:
> > Well, Eric, let's start with you: Would you be in support of moving
> > Cassandra to a Maven build and abandoning Ant/Ivy or at least have the
> Ant
> > build deploy the necessary artifacts to the Maven repo?
>
> It would be more productive if you were to read issue 850 that Eric
> has linked twice before asking questions like this.
>

Maybe I'm blind but where does that issue answer my questions to Eric?

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Jonathan Ellis <jb...@gmail.com>]

On Fri, Apr 9, 2010 at 12:11 PM, Hannes Schmidt <ha...@eyealike.com> wrote:
> Well, Eric, let's start with you: Would you be in support of moving
> Cassandra to a Maven build and abandoning Ant/Ivy or at least have the Ant
> build deploy the necessary artifacts to the Maven repo?

It would be more productive if you were to read issue 850 that Eric
has linked twice before asking questions like this.

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Ryan Daum <ry...@thimbleware.com>]

Properly constructed Maven artifacts have to declare their license in their
POM, and there are maven plugins for checking license conformity.

R

On Fri, Apr 9, 2010 at 2:25 PM, Eric Evans <ee...@rackspace.com> wrote:

> On Fri, 2010-04-09 at 10:11 -0700, Hannes Schmidt wrote:
> > > https://issues.apache.org/jira/browse/CASSANDRA-850
> > >
> > > The highlights:
> > >
> > > You either (a) have to find a way to create binary artifacts that
> > > contain all of the necessary libs while satisfying their license
> > > requirements, or (b) turn the tide of public opinion and build
> > consensus
> > > that using maven to retrieve the dependencies post-download is OK.
> > >
> > >
> > The Maven build should produce as it's main artifact a slim jar that
> > contains only the classes and resources that are derived from the
> > sources
> > inside the project. Like every Maven-produced jar artifact, the slim
> > jar
> > would contain the pom.xml which would declare the slim jar's
> > dependencies.
> > The slim jar is for people who want to use Cassandra in a Maven
> > project.
> > They would simply declare a dependency on the slim jar in their
> > project and
> > Maven would pull that in along with the transitive dependencies, i.e.
> > the
> > slim jar's dependencies (for this to work, all of those dependencies
> > would
> > have to be available through a public repository which is what this
> > issue is
> > about).
> >
> > The Maven build would also produce an attached (Maven lingo) fat jar.
> > This
> > is a JAR that contains all classes and resources of Cassandra and its
> > dependencies rolled into a single JAR that's executable via "java
> > -jar".
> > This is also the artifact that the Download section would link to.
>
> As CASSANDRA-850 covers (and I summarized separately), we are required
> to conform to the individual license requirements of these third-party
> dependencies if we are to legally redistribute them. These requirements
> vary from license to license, and TTBOMK, there is no deterministic way
> to identify a license (including any additional provisions) and generate
> compliant artifacts.
>
> > Optionally, and as you already suggested, the client- or API-specific
> > stuff
> > could be factored out into a separate project.
> >
> >
> > > I wish you the best of luck (seriously).
> > >
> > >
> > Well, Eric, let's start with you: Would you be in support of moving
> > Cassandra to a Maven build and abandoning Ant/Ivy or at least have the
> > Ant
> > build deploy the necessary artifacts to the Maven repo?
>
> I don't like Maven either, but you aren't the first person to tell me I
> have it all Wrong. If someone were to do the work and demonstrably prove
> that there is a Better Way, as opposed to just telling me what I should
> do, I'd be open to a change.
>
> --
> Eric Evans
> eevans@rackspace.com
>
>

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Eric Evans <ee...@rackspace.com>]

On Fri, 2010-04-09 at 10:11 -0700, Hannes Schmidt wrote:
> > https://issues.apache.org/jira/browse/CASSANDRA-850
> >
> > The highlights:
> >
> > You either (a) have to find a way to create binary artifacts that
> > contain all of the necessary libs while satisfying their license
> > requirements, or (b) turn the tide of public opinion and build
> consensus
> > that using maven to retrieve the dependencies post-download is OK.
> >
> >
> The Maven build should produce as it's main artifact a slim jar that
> contains only the classes and resources that are derived from the
> sources
> inside the project. Like every Maven-produced jar artifact, the slim
> jar
> would contain the pom.xml which would declare the slim jar's
> dependencies.
> The slim jar is for people who want to use Cassandra in a Maven
> project.
> They would simply declare a dependency on the slim jar in their
> project and
> Maven would pull that in along with the transitive dependencies, i.e.
> the
> slim jar's dependencies (for this to work, all of those dependencies
> would
> have to be available through a public repository which is what this
> issue is
> about).
> 
> The Maven build would also produce an attached (Maven lingo) fat jar.
> This
> is a JAR that contains all classes and resources of Cassandra and its
> dependencies rolled into a single JAR that's executable via "java
> -jar".
> This is also the artifact that the Download section would link to.

As CASSANDRA-850 covers (and I summarized separately), we are required
to conform to the individual license requirements of these third-party
dependencies if we are to legally redistribute them. These requirements
vary from license to license, and TTBOMK, there is no deterministic way
to identify a license (including any additional provisions) and generate
compliant artifacts.

> Optionally, and as you already suggested, the client- or API-specific
> stuff
> could be factored out into a separate project.
> 
> 
> > I wish you the best of luck (seriously).
> >
> >
> Well, Eric, let's start with you: Would you be in support of moving
> Cassandra to a Maven build and abandoning Ant/Ivy or at least have the
> Ant
> build deploy the necessary artifacts to the Maven repo? 

I don't like Maven either, but you aren't the first person to tell me I
have it all Wrong. If someone were to do the work and demonstrably prove
that there is a Better Way, as opposed to just telling me what I should
do, I'd be open to a change.

-- 
Eric Evans
eevans@rackspace.com

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Hannes Schmidt <ha...@eyealike.com>]

On Fri, Apr 9, 2010 at 7:26 AM, Eric Evans <ee...@rackspace.com> wrote:

> On Fri, 2010-04-09 at 08:52 -0500, Jonathan Ellis wrote:
> > On Fri, Apr 9, 2010 at 8:21 AM, Gary Dusbabek <gd...@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.
> > >
> > > 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.
> >
> > It's still there in contrib/maven, btw.  No doubt somewhat bit-rotted.
>
> Required reading for anyone wishing to contribute maven support:
>
> https://issues.apache.org/jira/browse/CASSANDRA-850
>
> The highlights:
>
> You either (a) have to find a way to create binary artifacts that
> contain all of the necessary libs while satisfying their license
> requirements, or (b) turn the tide of public opinion and build consensus
> that using maven to retrieve the dependencies post-download is OK.
>
>
The Maven build should produce as it's main artifact a slim jar that
contains only the classes and resources that are derived from the sources
inside the project. Like every Maven-produced jar artifact, the slim jar
would contain the pom.xml which would declare the slim jar's dependencies.
The slim jar is for people who want to use Cassandra in a Maven project.
They would simply declare a dependency on the slim jar in their project and
Maven would pull that in along with the transitive dependencies, i.e. the
slim jar's dependencies (for this to work, all of those dependencies would
have to be available through a public repository which is what this issue is
about).

The Maven build would also produce an attached (Maven lingo) fat jar. This
is a JAR that contains all classes and resources of Cassandra and its
dependencies rolled into a single JAR that's executable via "java -jar".
This is also the artifact that the Download section would link to.

Optionally, and as you already suggested, the client- or API-specific stuff
could be factored out into a separate project.


> I wish you the best of luck (seriously).
>
>
Well, Eric, let's start with you: Would you be in support of moving
Cassandra to a Maven build and abandoning Ant/Ivy or at least have the Ant
build deploy the necessary artifacts to the Maven repo?


> --
> Eric Evans
> eevans@rackspace.com
>
>

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Eric Evans <ee...@rackspace.com>]

On Fri, 2010-04-09 at 08:52 -0500, Jonathan Ellis wrote:
> On Fri, Apr 9, 2010 at 8:21 AM, Gary Dusbabek <gd...@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.
> >
> > 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.
> 
> It's still there in contrib/maven, btw.  No doubt somewhat bit-rotted.

Required reading for anyone wishing to contribute maven support:

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

The highlights:

You either (a) have to find a way to create binary artifacts that
contain all of the necessary libs while satisfying their license
requirements, or (b) turn the tide of public opinion and build consensus
that using maven to retrieve the dependencies post-download is OK.

I wish you the best of luck (seriously).

-- 
Eric Evans
eevans@rackspace.com

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Jonathan Ellis <jb...@gmail.com>]

On Fri, Apr 9, 2010 at 8:21 AM, Gary Dusbabek <gd...@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.
>
> 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.

It's still there in contrib/maven, btw.  No doubt somewhat bit-rotted.

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Gary Dusbabek <gd...@gmail.com>]

On Fri, Apr 9, 2010 at 08:40, Ryan Daum <ry...@thimbleware.com> wrote:
>
> On Fri, Apr 9, 2010 at 9:21 AM, Gary Dusbabek <gd...@gmail.com> wrote:
>>
>>
>> I disagree that every project should do things the mvn way for the
>> sake of making things easier for mvn users.
>
> I'm sorry, do you not see the hypocrisy of saying this while referring to a
> project that retrieves its transitive dependencies from Maven repositories?
> Ryan
>

Irony, yes.  Hypocrisy, no.

If there were a dependency not hosted in a mvn repo, I'm happy to svn
add it to lib and be on my way.  Call me a hypocrite if I complain to
the maintainer about not pushing their work to a repo.

Gary

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Jesse McConnell <je...@gmail.com>]

I agree with Gary's comments even though I am certainly on the
pro-maven side of the issue..

if someone cares enough about it, it will get done

if I was using cassandra via a maven build I would have already
contributed the time to get the maven aspects of this in place, its
not a tremendous amount of work...but I am working in ant lands for
the time being so it hasn't been much of a priority

its all volunteer effort (or corporate sponsored effort, whatever the
case may be) so if someone cares enough about doing it, they'll do it.
 From what I have seen the dev's are not particularly motivated to
support maven better so they haven't, that is their prerogative.  They
have done more then some projects in saying they are not adverse to
having it done if someone else does it..:)

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@gmail.com



On Fri, Apr 9, 2010 at 08:40, Ryan Daum <ry...@thimbleware.com> wrote:
> On Fri, Apr 9, 2010 at 9:21 AM, Gary Dusbabek <gd...@gmail.com> wrote:
>
>>
>>
>> I disagree that every project should do things the mvn way for the
>> sake of making things easier for mvn users.
>
>
> I'm sorry, do you not see the hypocrisy of saying this while referring to a
> project that retrieves its transitive dependencies from Maven repositories?
>
> Ryan
>

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Ryan Daum <ry...@thimbleware.com>]

On Fri, Apr 9, 2010 at 9:21 AM, Gary Dusbabek <gd...@gmail.com> wrote:

>
>
> I disagree that every project should do things the mvn way for the
> sake of making things easier for mvn users.


I'm sorry, do you not see the hypocrisy of saying this while referring to a
project that retrieves its transitive dependencies from Maven repositories?

Ryan

Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)

[Gary Dusbabek <gd...@gmail.com>]

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 will try to put my prejudices aside as I make a few points though.

On Thu, Apr 8, 2010 at 19:42, Hannes Schmidt <ha...@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.

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.

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

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

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

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
>