Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
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 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 >
Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
On Fri, Apr 9, 2010 at 9:21 AM, Gary Dusbabek 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)
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.mcconn...@gmail.com On Fri, Apr 9, 2010 at 08:40, Ryan Daum wrote: > On Fri, Apr 9, 2010 at 9:21 AM, Gary Dusbabek 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)
On Fri, Apr 9, 2010 at 8:21 AM, Gary Dusbabek 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)
On Fri, Apr 9, 2010 at 08:40, Ryan Daum wrote: > > On Fri, Apr 9, 2010 at 9:21 AM, Gary Dusbabek 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)
On Fri, 2010-04-09 at 08:52 -0500, Jonathan Ellis wrote: > On Fri, Apr 9, 2010 at 8:21 AM, Gary Dusbabek 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 eev...@rackspace.com
python web framework suggestions (for Cassandra Web UI) needed
Hi! I made a proposal about building a Cassandra Web UI. One of it's main components, will be Python on the server side. However, as Gary D. pointed out, it will be interesting to get your opinions on which framework to use. I suggested Django for being well-known and largely documented, but any other would do. As far as my experience goes on web development, this is what I -IMHO- think of any web framework, despite the language: - Really small footprint is a plus: "do we really need to include that, and that, and that other thing?" - Flexibility and freedom of code, another plus: "do I really need to inherit that class to do that" - Unneeded features tend to get in our way: like the "auto admin" panels of Django. Or the "FormAlchemy" and "SQLAlchemy" features in Pylons. - Templating features should be truly flexible, and do fast template parsing. Well, suggestions are needed! I would like to know your opinions on Django, Pylons, web2py, TurboGears, etc. Regards!
Re: python web framework suggestions (for Cassandra Web UI) needed
I like pylons. Easy templating and relatively light weight. In my experience, it was easier to get something working in pylons than django, but I am impatient. Gary. On Fri, Apr 9, 2010 at 09:55, Pablo Cuadrado wrote: > Hi! > > I made a proposal about building a Cassandra Web UI. One of it's main > components, will be Python on the server side. > > However, as Gary D. pointed out, it will be interesting to get your > opinions on which framework to use. > > I suggested Django for being well-known and largely documented, but > any other would do. > > As far as my experience goes on web development, this is what I -IMHO- > think of any web framework, despite the language: > > - Really small footprint is a plus: "do we really need to include > that, and that, and that other thing?" > - Flexibility and freedom of code, another plus: "do I really need to > inherit that class to do that" > - Unneeded features tend to get in our way: like the "auto admin" > panels of Django. Or the "FormAlchemy" and "SQLAlchemy" features in > Pylons. > - Templating features should be truly flexible, and do fast template parsing. > > Well, suggestions are needed! I would like to know your opinions on > Django, Pylons, web2py, TurboGears, etc. > > Regards! >
FW: Friendly Reminder: Google SoC Student Application Deadline is Today at 19:00 UTC
For all the potential GSoC students ... -- Forwarded Message From: Carol Smith Reply-To: Date: Fri, 9 Apr 2010 08:18:53 -0700 To: Google Summer of Code Announce Subject: Friendly Reminder: Student Application Deadline is Today at 19:00 UTC Hi everyone, Just a quick reminder that the deadline for student applications is today at 19:00 UTC. Please don't wait until the last minute to submit! Here's a handy time zone converter: http://bit.ly/bP1fXT Cheers, Carol -- -- End of Forwarded Message
Re: python web framework suggestions (for Cassandra Web UI) needed
+1 for pylons, I've been quite happy with it so far - lightweight, very flexible, loosely coupled components... On Apr 9, 2010, at 10:23 AM, Gary Dusbabek wrote: I like pylons. Easy templating and relatively light weight. In my experience, it was easier to get something working in pylons than django, but I am impatient. Gary. On Fri, Apr 9, 2010 at 09:55, Pablo Cuadrado wrote: Hi! I made a proposal about building a Cassandra Web UI. One of it's main components, will be Python on the server side. However, as Gary D. pointed out, it will be interesting to get your opinions on which framework to use. I suggested Django for being well-known and largely documented, but any other would do. As far as my experience goes on web development, this is what I - IMHO- think of any web framework, despite the language: - Really small footprint is a plus: "do we really need to include that, and that, and that other thing?" - Flexibility and freedom of code, another plus: "do I really need to inherit that class to do that" - Unneeded features tend to get in our way: like the "auto admin" panels of Django. Or the "FormAlchemy" and "SQLAlchemy" features in Pylons. - Templating features should be truly flexible, and do fast template parsing. Well, suggestions are needed! I would like to know your opinions on Django, Pylons, web2py, TurboGears, etc. Regards!
Re: python web framework suggestions (for Cassandra Web UI) needed
Way back when I wanted to try and use node.js and Cassandra, I started work on a restful interface using Tornado and Lazyboy. I've since moved on from that idea and the project is way out of date, but you can see what I had done at this project on github - http://github.com/joerussbowman/jsondra On Fri, Apr 9, 2010 at 11:49 AM, Matthew Dennis wrote: > +1 for pylons, I've been quite happy with it so far - lightweight, very > flexible, loosely coupled components... > > > On Apr 9, 2010, at 10:23 AM, Gary Dusbabek wrote: > > I like pylons. Easy templating and relatively light weight. In my >> experience, it was easier to get something working in pylons than >> django, but I am impatient. >> >> Gary. >> >> >> On Fri, Apr 9, 2010 at 09:55, Pablo Cuadrado >> wrote: >> >>> Hi! >>> >>> I made a proposal about building a Cassandra Web UI. One of it's main >>> components, will be Python on the server side. >>> >>> However, as Gary D. pointed out, it will be interesting to get your >>> opinions on which framework to use. >>> >>> I suggested Django for being well-known and largely documented, but >>> any other would do. >>> >>> As far as my experience goes on web development, this is what I -IMHO- >>> think of any web framework, despite the language: >>> >>> - Really small footprint is a plus: "do we really need to include >>> that, and that, and that other thing?" >>> - Flexibility and freedom of code, another plus: "do I really need to >>> inherit that class to do that" >>> - Unneeded features tend to get in our way: like the "auto admin" >>> panels of Django. Or the "FormAlchemy" and "SQLAlchemy" features in >>> Pylons. >>> - Templating features should be truly flexible, and do fast template >>> parsing. >>> >>> Well, suggestions are needed! I would like to know your opinions on >>> Django, Pylons, web2py, TurboGears, etc. >>> >>> Regards! >>> >>>
Re: python web framework suggestions (for Cassandra Web UI) needed
I like Pylons also, for what I've read. Haven't worked with it so far, but I'll give it try today to see how it performs. Joseph: That's great! I'm also thinking on Lazyboy, and a restful interface. I'll take a look at it. On Fri, Apr 9, 2010 at 1:10 PM, Joseph Bowman wrote: > Way back when I wanted to try and use node.js and Cassandra, I started work > on a restful interface using Tornado and Lazyboy. I've since moved on from > that idea and the project is way out of date, but you can see what I had > done at this project on github - http://github.com/joerussbowman/jsondra > > On Fri, Apr 9, 2010 at 11:49 AM, Matthew Dennis wrote: > >> +1 for pylons, I've been quite happy with it so far - lightweight, very >> flexible, loosely coupled components... >> >> >> On Apr 9, 2010, at 10:23 AM, Gary Dusbabek wrote: >> >> I like pylons. Easy templating and relatively light weight. In my >>> experience, it was easier to get something working in pylons than >>> django, but I am impatient. >>> >>> Gary. >>> >>> >>> On Fri, Apr 9, 2010 at 09:55, Pablo Cuadrado >>> wrote: >>> Hi! I made a proposal about building a Cassandra Web UI. One of it's main components, will be Python on the server side. However, as Gary D. pointed out, it will be interesting to get your opinions on which framework to use. I suggested Django for being well-known and largely documented, but any other would do. As far as my experience goes on web development, this is what I -IMHO- think of any web framework, despite the language: - Really small footprint is a plus: "do we really need to include that, and that, and that other thing?" - Flexibility and freedom of code, another plus: "do I really need to inherit that class to do that" - Unneeded features tend to get in our way: like the "auto admin" panels of Django. Or the "FormAlchemy" and "SQLAlchemy" features in Pylons. - Templating features should be truly flexible, and do fast template parsing. Well, suggestions are needed! I would like to know your opinions on Django, Pylons, web2py, TurboGears, etc. Regards! >
Re: python web framework suggestions (for Cassandra Web UI) needed
Lazyboy has had a lot of updates since the implementation that's in place there. Those Digg guys have been busy. So I wouldn't use jsondra as much more than an example of how to use tornado for the framework, rather than to build off of as I imagine the lazyboy usage is different with current versions. And tornado has been updated as well since, some. On Fri, Apr 9, 2010 at 12:23 PM, Pablo Cuadrado wrote: > I like Pylons also, for what I've read. Haven't worked with it so far, > but I'll give it try today to see how it performs. > > Joseph: That's great! I'm also thinking on Lazyboy, and a restful > interface. I'll take a look at it. > > > > On Fri, Apr 9, 2010 at 1:10 PM, Joseph Bowman > wrote: > > Way back when I wanted to try and use node.js and Cassandra, I started > work > > on a restful interface using Tornado and Lazyboy. I've since moved on > from > > that idea and the project is way out of date, but you can see what I had > > done at this project on github - http://github.com/joerussbowman/jsondra > > > > On Fri, Apr 9, 2010 at 11:49 AM, Matthew Dennis > wrote: > > > >> +1 for pylons, I've been quite happy with it so far - lightweight, very > >> flexible, loosely coupled components... > >> > >> > >> On Apr 9, 2010, at 10:23 AM, Gary Dusbabek wrote: > >> > >> I like pylons. Easy templating and relatively light weight. In my > >>> experience, it was easier to get something working in pylons than > >>> django, but I am impatient. > >>> > >>> Gary. > >>> > >>> > >>> On Fri, Apr 9, 2010 at 09:55, Pablo Cuadrado > >>> wrote: > >>> > Hi! > > I made a proposal about building a Cassandra Web UI. One of it's main > components, will be Python on the server side. > > However, as Gary D. pointed out, it will be interesting to get your > opinions on which framework to use. > > I suggested Django for being well-known and largely documented, but > any other would do. > > As far as my experience goes on web development, this is what I -IMHO- > think of any web framework, despite the language: > > - Really small footprint is a plus: "do we really need to include > that, and that, and that other thing?" > - Flexibility and freedom of code, another plus: "do I really need to > inherit that class to do that" > - Unneeded features tend to get in our way: like the "auto admin" > panels of Django. Or the "FormAlchemy" and "SQLAlchemy" features in > Pylons. > - Templating features should be truly flexible, and do fast template > parsing. > > Well, suggestions are needed! I would like to know your opinions on > Django, Pylons, web2py, TurboGears, etc. > > Regards! > > > > >
Re: python web framework suggestions (for Cassandra Web UI) needed
I like Django. Its wide adoption, great docs and included batteries make it an easy sell. But what your describing is more like a pylons, aka if you dont want an orm in Pylons, don't include it. On Fri, Apr 9, 2010 at 8:49 AM, Matthew Dennis wrote: > +1 for pylons, I've been quite happy with it so far - lightweight, very > flexible, loosely coupled components... > > On Apr 9, 2010, at 10:23 AM, Gary Dusbabek wrote: > >> I like pylons. Easy templating and relatively light weight. In my >> experience, it was easier to get something working in pylons than >> django, but I am impatient. >> >> Gary. >> >> >> On Fri, Apr 9, 2010 at 09:55, Pablo Cuadrado >> wrote: >>> >>> Hi! >>> >>> I made a proposal about building a Cassandra Web UI. One of it's main >>> components, will be Python on the server side. >>> >>> However, as Gary D. pointed out, it will be interesting to get your >>> opinions on which framework to use. >>> >>> I suggested Django for being well-known and largely documented, but >>> any other would do. >>> >>> As far as my experience goes on web development, this is what I -IMHO- >>> think of any web framework, despite the language: >>> >>> - Really small footprint is a plus: "do we really need to include >>> that, and that, and that other thing?" >>> - Flexibility and freedom of code, another plus: "do I really need to >>> inherit that class to do that" >>> - Unneeded features tend to get in our way: like the "auto admin" >>> panels of Django. Or the "FormAlchemy" and "SQLAlchemy" features in >>> Pylons. >>> - Templating features should be truly flexible, and do fast template >>> parsing. >>> >>> Well, suggestions are needed! I would like to know your opinions on >>> Django, Pylons, web2py, TurboGears, etc. >>> >>> Regards! >>> > -- Dan Di Spaltro
Re: python web framework suggestions (for Cassandra Web UI) needed
Joseph: Of course, I understand it's out of date but I'm sure it worths a look! Dan: You're right, it looks like Pylons is more suitable. Some pro's I see: - Mako seems to be a faster template engine than Django's one. - Looks to be really WSGI oriented from scratch. - As for the ORM, it just won't be suitable for Cassandra, ORMs nowadays are built obviously to work on the usual RDBMS... Now, I was just thinking, in terms of "objects" and "relational mapping", I'm guessing that "object mapping" is even easier in Cassandra than in a complex relational database. I had some nightmares working with DoctrineORM and PHP with largely normalized complex databases... On Fri, Apr 9, 2010 at 1:29 PM, Dan Di Spaltro wrote: > I like Django. Its wide adoption, great docs and included batteries > make it an easy sell. > > But what your describing is more like a pylons, aka if you dont want > an orm in Pylons, don't include it. > > On Fri, Apr 9, 2010 at 8:49 AM, Matthew Dennis wrote: >> +1 for pylons, I've been quite happy with it so far - lightweight, very >> flexible, loosely coupled components... >> >> On Apr 9, 2010, at 10:23 AM, Gary Dusbabek wrote: >> >>> I like pylons. Easy templating and relatively light weight. In my >>> experience, it was easier to get something working in pylons than >>> django, but I am impatient. >>> >>> Gary. >>> >>> >>> On Fri, Apr 9, 2010 at 09:55, Pablo Cuadrado >>> wrote: Hi! I made a proposal about building a Cassandra Web UI. One of it's main components, will be Python on the server side. However, as Gary D. pointed out, it will be interesting to get your opinions on which framework to use. I suggested Django for being well-known and largely documented, but any other would do. As far as my experience goes on web development, this is what I -IMHO- think of any web framework, despite the language: - Really small footprint is a plus: "do we really need to include that, and that, and that other thing?" - Flexibility and freedom of code, another plus: "do I really need to inherit that class to do that" - Unneeded features tend to get in our way: like the "auto admin" panels of Django. Or the "FormAlchemy" and "SQLAlchemy" features in Pylons. - Templating features should be truly flexible, and do fast template parsing. Well, suggestions are needed! I would like to know your opinions on Django, Pylons, web2py, TurboGears, etc. Regards! >> > > > > -- > Dan Di Spaltro >
Re: python web framework suggestions (for Cassandra Web UI) needed
On Fri, Apr 9, 2010 at 4:55 PM, Pablo Cuadrado wrote: > - Really small footprint is a plus: "do we really need to include > that, and that, and that other thing?" as I can imagine your app won't have any state per se, so you don't have any DB issues, you probably won't even need sessions, why not use simpler environments? I loved CherryPy some years ago, and there are plenty of new microframeworks such as Bottle which seem more fitting to _this_ bullet point than django and pylons.
Re: python web framework suggestions (for Cassandra Web UI) needed
Gabriele: Yes, the idea is to make it light-weighted. However, I may add: it would be nice (for us all) to use a framework which the community feels comfortable with. I'm trying to find a balance between features and footprint, having a small footprint is very important, but also, we want something scalable for adding features on next versions of the UI. Sessions, IMHO, are useful in many ways on web interfaces, for example, in user authentication (which the UI should have), preferences, etc. On Fri, Apr 9, 2010 at 1:42 PM, gabriele renzi wrote: > On Fri, Apr 9, 2010 at 4:55 PM, Pablo Cuadrado > wrote: >> - Really small footprint is a plus: "do we really need to include >> that, and that, and that other thing?" > > as I can imagine your app won't have any state per se, so you don't > have any DB issues, you probably won't even need sessions, why not use > simpler environments? I loved CherryPy some years ago, and there are > plenty of new microframeworks such as Bottle which seem more fitting > to _this_ bullet point than django and pylons. >
Re: python web framework suggestions (for Cassandra Web UI) needed
Well Tornado is light weight, it is it's own web server as well, so no need to run something like apache in front of it, and is a nice light framework. It's an eventd style process, so supports lots of connections very well, which would give you more flexibility is designing clients to work with it. http://www.tornadoweb.org/ On Fri, Apr 9, 2010 at 12:51 PM, Pablo Cuadrado wrote: > Gabriele: > > Yes, the idea is to make it light-weighted. However, I may add: it > would be nice (for us all) to use a framework which the community > feels comfortable with. > > I'm trying to find a balance between features and footprint, having a > small footprint is very important, but also, we want something > scalable for adding features on next versions of the UI. > > Sessions, IMHO, are useful in many ways on web interfaces, for > example, in user authentication (which the UI should have), > preferences, etc. > > On Fri, Apr 9, 2010 at 1:42 PM, gabriele renzi wrote: > > On Fri, Apr 9, 2010 at 4:55 PM, Pablo Cuadrado > wrote: > >> - Really small footprint is a plus: "do we really need to include > >> that, and that, and that other thing?" > > > > as I can imagine your app won't have any state per se, so you don't > > have any DB issues, you probably won't even need sessions, why not use > > simpler environments? I loved CherryPy some years ago, and there are > > plenty of new microframeworks such as Bottle which seem more fitting > > to _this_ bullet point than django and pylons. > > >
Re: python web framework suggestions (for Cassandra Web UI) needed
On Fri, Apr 9, 2010 at 11:42 AM, gabriele renzi wrote: > On Fri, Apr 9, 2010 at 4:55 PM, Pablo Cuadrado > wrote: > > - Really small footprint is a plus: "do we really need to include > > that, and that, and that other thing?" > > as I can imagine your app won't have any state per se, so you don't > have any DB issues, you probably won't even need sessions, why not use > simpler environments? I loved CherryPy some years ago, and there are > plenty of new microframeworks such as Bottle which seem more fitting > to _this_ bullet point than django and pylons. > Pylons makes it easy to add/remove/change the way sessions are done, this is one of the reasons I like it so much - nearly everything is easy to disable or replace. Don't want sessions? You don't have to include them in Pylons. Want to store them only in a encrypted cookie or only on disk or only in a RDMBS? no problem. Want to store sessions in Cassandra (which if you use them, I imagine you do)? It's simple enough to add that, the main part you have to write is the storage and retrieval to/from Cassandra - the rest is basically a small bit of config that says "use this other thing for storing sessions"
Re: python web framework suggestions (for Cassandra Web UI) needed
Joseph: Is it somehow similar to Twisted? am I wrong? On Fri, Apr 9, 2010 at 1:55 PM, Joseph Bowman wrote: > Well Tornado is light weight, it is it's own web server as well, so no need > to run something like apache in front of it, and is a nice light framework. > It's an eventd style process, so supports lots of connections very well, > which would give you more flexibility is designing clients to work with it. > > http://www.tornadoweb.org/ > > On Fri, Apr 9, 2010 at 12:51 PM, Pablo Cuadrado > wrote: > >> Gabriele: >> >> Yes, the idea is to make it light-weighted. However, I may add: it >> would be nice (for us all) to use a framework which the community >> feels comfortable with. >> >> I'm trying to find a balance between features and footprint, having a >> small footprint is very important, but also, we want something >> scalable for adding features on next versions of the UI. >> >> Sessions, IMHO, are useful in many ways on web interfaces, for >> example, in user authentication (which the UI should have), >> preferences, etc. >> >> On Fri, Apr 9, 2010 at 1:42 PM, gabriele renzi wrote: >> > On Fri, Apr 9, 2010 at 4:55 PM, Pablo Cuadrado >> wrote: >> >> - Really small footprint is a plus: "do we really need to include >> >> that, and that, and that other thing?" >> > >> > as I can imagine your app won't have any state per se, so you don't >> > have any DB issues, you probably won't even need sessions, why not use >> > simpler environments? I loved CherryPy some years ago, and there are >> > plenty of new microframeworks such as Bottle which seem more fitting >> > to _this_ bullet point than django and pylons. >> > >> >
Re: python web framework suggestions (for Cassandra Web UI) needed
On Fri, Apr 9, 2010 at 11:57 AM, Pablo Cuadrado wrote: > Joseph: > > Is it somehow similar to Twisted? am I wrong? Yes, minus every protocol other than HTTP, daemonization utils, etc. Oh, and thrift doesn't have a generator for it last I checked. -Brandon
Re: python web framework suggestions (for Cassandra Web UI) needed
A little different approach than Twisted, a lot less there, and yea no thrift generator, but if you plan on using Lazyboy you'd be fine. On Fri, Apr 9, 2010 at 12:59 PM, Brandon Williams wrote: > On Fri, Apr 9, 2010 at 11:57 AM, Pablo Cuadrado >wrote: > > > Joseph: > > > > Is it somehow similar to Twisted? am I wrong? > > > Yes, minus every protocol other than HTTP, daemonization utils, etc. Oh, > and thrift doesn't have a generator for it last I checked. > > -Brandon >
Re: python web framework suggestions (for Cassandra Web UI) needed
Yes, I'm planning on Lazyboy. The Performance part on the Tornado wiki is quite impressive. Do you think it's accurate? http://www.tornadoweb.org/documentation#performance On Fri, Apr 9, 2010 at 2:02 PM, Joseph Bowman wrote: > A little different approach than Twisted, a lot less there, and yea no > thrift generator, but if you plan on using Lazyboy you'd be fine. > > On Fri, Apr 9, 2010 at 12:59 PM, Brandon Williams wrote: > >> On Fri, Apr 9, 2010 at 11:57 AM, Pablo Cuadrado > >wrote: >> >> > Joseph: >> > >> > Is it somehow similar to Twisted? am I wrong? >> >> >> Yes, minus every protocol other than HTTP, daemonization utils, etc. Oh, >> and thrift doesn't have a generator for it last I checked. >> >> -Brandon >> >
Re: python web framework suggestions (for Cassandra Web UI) needed
On Fri, Apr 9, 2010 at 12:04 PM, Pablo Cuadrado wrote: > Yes, I'm planning on Lazyboy. > > The Performance part on the Tornado wiki is quite impressive. Do you > think it's accurate? > > http://www.tornadoweb.org/documentation#performance Using Lazyboy, you'd be mixing blocking sockets with a nonblocking event loop, so performance is likely less than optimal. That said, I doubt performance is a concern with a web UI. -Brandon
Re: python web framework suggestions (for Cassandra Web UI) needed
I don't really consider any hello world benchmarks valid, you'd want to investigate what your implementation would entail in different frameworks and do mini-benchmarks to validate which is faster. But, if it's just a web framework, as Brandon said, I doubt performance will matter to any great degree. You'd be more concerned about Cassandra's performance, which is pretty darn good. On Fri, Apr 9, 2010 at 1:07 PM, Brandon Williams wrote: > On Fri, Apr 9, 2010 at 12:04 PM, Pablo Cuadrado >wrote: > > > Yes, I'm planning on Lazyboy. > > > > The Performance part on the Tornado wiki is quite impressive. Do you > > think it's accurate? > > > > http://www.tornadoweb.org/documentation#performance > > > Using Lazyboy, you'd be mixing blocking sockets with a nonblocking event > loop, so performance is likely less than optimal. That said, I doubt > performance is a concern with a web UI. > > -Brandon >
Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
On Fri, Apr 9, 2010 at 7:26 AM, Eric Evans wrote: > On Fri, 2010-04-09 at 08:52 -0500, Jonathan Ellis wrote: > > On Fri, Apr 9, 2010 at 8:21 AM, Gary Dusbabek > 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 > eev...@rackspace.com > >
Re: python web framework suggestions (for Cassandra Web UI) needed
It is indeed a web framework, and made for sys admins to interact with Cassandra, not for hosting millions of users concurrently. And you're right: those are helloworld benchmarks. I was concerned a few days ago about the sync/async issue, browsing over examples on Telephus, Twissandra, Lazyboy, Pycassa... then I thought that Lazyboy is largely being used in production AFAIK, so I've just kept it in my mind. However, the communication layer for the web UI, should (and hopefully it will) be independent, in case we want to make this changes in the future. On Fri, Apr 9, 2010 at 2:10 PM, Joseph Bowman wrote: > I don't really consider any hello world benchmarks valid, you'd want to > investigate what your implementation would entail in different frameworks > and do mini-benchmarks to validate which is faster. But, if it's just a web > framework, as Brandon said, I doubt performance will matter to any great > degree. You'd be more concerned about Cassandra's performance, which is > pretty darn good. > > On Fri, Apr 9, 2010 at 1:07 PM, Brandon Williams wrote: > >> On Fri, Apr 9, 2010 at 12:04 PM, Pablo Cuadrado > >wrote: >> >> > Yes, I'm planning on Lazyboy. >> > >> > The Performance part on the Tornado wiki is quite impressive. Do you >> > think it's accurate? >> > >> > http://www.tornadoweb.org/documentation#performance >> >> >> Using Lazyboy, you'd be mixing blocking sockets with a nonblocking event >> loop, so performance is likely less than optimal. That said, I doubt >> performance is a concern with a web UI. >> >> -Brandon >> >
Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
On Fri, Apr 9, 2010 at 12:11 PM, Hannes Schmidt 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)
On Fri, Apr 9, 2010 at 6:21 AM, Gary Dusbabek 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 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)
On Fri, Apr 9, 2010 at 10:41 AM, Jonathan Ellis wrote: > On Fri, Apr 9, 2010 at 12:11 PM, Hannes Schmidt > 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)
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 eev...@rackspace.com
Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
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 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 > eev...@rackspace.com > >
Re: Thoughts on issue 697 (Mitigate unpublished dependencies when using Cassandra with Maven)
On Fri, Apr 9, 2010 at 12:42, Hannes Schmidt wrote: > On Fri, Apr 9, 2010 at 6:21 AM, Gary Dusbabek 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)
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
