Re: [Stripes-users] IMPORTANT:: Developing stripes (Future... Part DEUX)

[Jeppe Cramon]

Hi Remi Long time :) IMO forking is a good thing, IF it's done in Git style where it easy to keep up with those who have forked the master and push/pull between those interested :) It makes it so much easier to experiment and do patches and leave them for everyone to see, including the Stripes comitter, if it's hosted in you own GitHub repository. Having to fetch Strips sourcecode from SVN, create a patch file and send it in and hope that someone will accept it, is just too 2000 ;) /Jeppe On Tue, 21 Sep 2010 16:25:19 +0200, VANKEISBELCK Remi <r...@rvkb.com> wrote: Hi folks I've been following this thread not really knwoing how to responde, Ben, you took the words out of my mouth :) I'm also perfeclty happy with Stripes as is. Sure more developers would be agood thing. But forking like crazy etc... not sure this will help. Nothing prevents anyone to experiment with the codebase, and send their contribs. I have no doubts they will be accepted if they are worth it, and inline with the Stripes spirit.   Cheers Remi 2010/9/21 Ben Gunter <gunter...@gmail.com> Well, it looks like life picked a bad time to get busy for me. I just now got around to catching up on this thread. I'm sure my silence caused some concern. Sorry about that. I completely agree with the sentiment that we need eager new developers to contribute to the project. Those who know me know that I'm not about politics or control or ego. I would love to bring some eager new developers in to help rejuvenate the project. There was a time a few years ago when I had that same enthusiasm for developing Stripes. I answered lots of questions on the mailing list with tons of code samples. I started the Stripes Extras project to add some security to the binding stage so developers wouldn't have to worry about evil stuff getting poked into their ActionBeans. I had bigger plans for Stripes Extras, but Tim took notice of my activity and invited me to contribute directly to the Stripes core. I accepted, and the features of Stripes Extras were merged in for Stripes 1.5. Freddy and Aaron and a few others joined in on the 1.5 effort, and we finally released what I think is a pretty nice product: binding security, clean URLs, DynamicMappingFilter, minimal configuration, improved type conversion and formatting. Not too shabby. What we were then was a great group of developers with a clear vision for what we wanted Stripes to be and a singular focus on making it happen. What we are now is a great group of developers who have a framework with which we're quite satisfied. I remember clearly that when Tim brought me in he said -- I think it was on IRC -- that he was happy with Stripes as it was. That is where I stand now. Like Tim was then, I am happy to hand over the reins to someone who can drive the project forward, while offering any help I can along the way. Over the last few years, I have heard time and time again the chorus of "we should do this" or "we should do that." What I have learned, though, is that more often than not it really means "you should do this" or "you should do that." I have poured hours and hours into finding and fixing bugs that do not affect me personally. Generally, it's very difficult to get cooperation from people in testing patches to ensure the bug they've reported is fixed. Complaints about how something works or does not work are rarely accompanied by a solution to the perceived problem. My point is that talk is cheap. Who out there is really willing to dig in and learn the Stripes code and dedicate a good chunk of time on a regular basis to make it better? Who is willing to design a new web site? Who is willing to review and correct and improve the documentation? Who is willing create and maintain a Stripes-centric blog with regular articles? If you are willing and able *right now* to start making a real contribution to the project, then respond to this email and commit to it. Let us know your name, your history with Stripes, how you want to contribute, and any other information that you think is relevant. If you can't contribute now but hope to be able to in the future, then please wait until that time comes to speak up. What I want is to know who we have in this group who can help breathe new life into Stripes starting today. Let's hear it. -Ben On Sun, Sep 19, 2010 at 2:51 PM, Jeppe Cramon <je...@cramon.dk> wrote: Hi guys I've been following this resurrection thread for a while and even though I contributed some core parts to Stripes in the early days I haven't really had the need for something like Stripes in a long time (for instance it lacks proper REST and Comet style support). IMO Stripes has faded because it has been too difficult to participate, add patches and features. I like that the core of Stripes is kept tight, with focus on extensibility and what's the core things for an Action based MVC framework. The low learning curve and the easy extensibility was what attracted me to Stripes in the first place, but the lack of progress & new releases is hurting Stripes. Since this thread has appeared and have started a good discussion, I think it's important to reach a consensus on where to take Stripes. IMO if this thread dies out with any clear forward action, then Stripes is going to whither. I agree with Rick, forking would be a good way to move forward. My suggestion is to put Stripes on GitHub and allow people for Fork it like crazy - see what the community can come up with and harvest the best ideas by pulling from the best contributers. But IMO it's important that someone like Ben, Aaron or Freddy be the one(s) maintaining the "official" Git Master and decide what gets pulled into the official Stripes release. Perhaps someone will come by and create a fork that blows everyone away - let's see what could happen ;) /Jeppe On Sun, 19 Sep 2010 20:27:21 +0200, Rick Grashel <rgras...@gmail.com> wrote: Evan, Regarding your comment about forking the code being a last resort, I'm not too sure about that.  In fact, I think forks are absolutely critical when an OSS project is at a plateau.  Forking gets a really bad name, but I think it is critical to a project's evolution.  Some of the most successful OSS projects out there were a result of forks. Especially when you look at a Linux distribution like Ubuntu.  Ubuntu really was forked just to get more frequent and fresh releases.  Even today, it still maintains the Debian base.  It has a couple of add-on features.  I could easily see Stripes doing this.  All it really takes is a few people who are willing to prioritize some goals (usually high-impact defects or enhancement requests)... and then the fork is done.  In my opinion, a fork is necessary with Stripes right now.  No release in 9 months.  A growing backlog of high-impact items.  A community that is expressing serious concern.  Code that is committed or offered to be committed without review or response.  Nobody who can really hands the keys over.  Sounds like the makings of a fork to me.  Someone just needs to step forward and do it.  Personally, I would hope one of the original code contributors would do it -- and then take a passive role.  But usually for political or personal reasons, that isn't done. -- Rick On Sat, Sep 18, 2010 at 7:02 PM, Evan Leonard <evan.leon...@gmail.com> wrote: Nikolaos, Thank you for the thoughtful summary of the state of things. Since I just popped up here recently with my opinions, I thought it might be useful to introduce myself briefly, so people know where I'm coming from. Starting in 2003, I began working at a startup in the SOAP/SOA world. We built a product using Struts 1.1 which was "the best thing at the time".  And I worked to overcoming its warts. I added flash scope, view models, and a number of other things by extending the core struts processor. I started down the road of creating some fancy-pants UI controls that would maintain their state seemlessly across request cycles using a viewstate concept like ASP.NET. (I abandoned this idea later, but want to give you an idea of the experiments I did working with struts).  By the time the app was done we had a 1400+ line struts.config file. I know the pains of struts well. Since then I've gone looking for something better. While still at that company we tried Grails, by bringing in the old app under a new grails app using the grails-struts plugin. Grails was, well, disappointing. You never can get away from the fact that groovy compiles to java before compiling to bytecode. The amount of reflection that happens to make a single method call is astounding. And then there's the magic stuff that appears in context somehow, and you have noway of knowing without digging through the documentation. Which brings me to rails. I've tried to prototype a number of things in Rails, and for all its buzz about being fast to develop, it never felt fast to me. The amount of time I spent going through documentation to understand what's in context was frustrating.  I'm sure its super fast once you've spent a thousand hours learning it, but the ramp-up time is deceiving. There are a number of good things to learn from the design of the platform and the organization of community ecosystem however. ( (I won't bother covering my opinions about Springsource. Others have stated the situation there well already) So, when recently I needed to select a new web framework and was pointed to Stripes by a former colleague and friend of mine I liked what I saw.  The ability to customize Stripes is great (for the most part), the way it can be made to work with other frameworks is great (for the most part).  But before committing to using it for the next year or more, I would really like to see an active community around it. Where there is a clear process for giving feedback, submitting patches, and generally contributing. This is the one area that is currently lacking. Yes, there are all the perception problems too that people have discussed. But if those are solved and there is still no clear way to contribute to the project, then the new interest won't turn into new activity. Stripes isn't perfect, I'm looking at integrating a different db layer other than hibernate, and I've found a few places I would like to be able to hook that are not currently hookable. I would like to be able to have my validations on my model classes and have them carried through to the view by Stripe's validation layer.  But I don't know who to talk with to make these things happen. I've seen other projects come to forking the code when the current owners of the project aren't able to continue or turn things over to others. That's usually the last resort. I certainly don't have the time to become a core maintainer on a project. But I do have time (and experience) to help a community organize itself around a good purpose. And it sounds like continuing the spirit of Stripes is a good purpose. So with that, I hope to hear from the folks in the "core" currently.  I hope we can engage in some discussion about what the next steps are with respect to code ownership and the contribution process. Thanks so much for all the work that been put into this project so far. All the best, Evan Leonard On Sep 18, 2010, at 10:09 AM, Nikolaos Giannopoulos wrote: > Ben, > > You have made it clear that you needed to get away from the code back in > June after having made a flurry of commits.  Everyone understands and > appreciates what you have done for Stripes as you have single handedly > maintained Stripes for quite some time (I assume since its beginnings > with Tim) and have been an incredible driving force IMO. > > But the time of a single developer cobbling together code OR merely > accepting patches that are ready and tested from the community - but not > having the time to integrate them - must be over.  At some point in time > we need to stand aside to see a project grow otherwise we will - and not > to be dramatic - smother it and indeed it will die... . > > There are developers like Evan, Nicolai, myself (down the road) and > others in the wings (whose names I don't have readily with me but have > voiced themselves already) that are "ready" to get involved **today** > and / or contribute their extensions that they have built for their real > world projects... and yet the lack of response to requests on how to get > involved is quite unsettling to say the least. > > Another area... 1.5.3 was released on December 16, 2009 yet a full 9 > months later it still does not appear in Maven Central.  One suggested > solution was to setup a Sonatype repo  for Stripes so that it > automatically syncs to Maven Central.  In STS-738 back in May of this > year you said "In case you missed my note on the mailing list the other > day, I'm working on getting this going through Sonatype. I'll resolve > this issue when it's done."  The fact that it isn't setup is not my > biggest concern and is not a problem as in the end you volunteer your > efforts / time. > > However since then others including Samuel Santos and Nathan Maves have > offered to help setup a Sonatype repo for Stripes - which they both have > stated they have experience doing - yet once again no reply to their > offers to help.  Once again this is unsettling... . > > This thread is by no means meant to be critical of your contributions... > as they most likely overshadow everyone else's in this community for > their extent and dedication.  This is meant more as a wake up call to > all those that hold the keys to Stripes.  I assume that includes > yourself, Freddy and Aaron but don't know for sure... . > > In my mind 3 things need to happen for Stripes to prosper: > > 1)  Getting Stripes automatically sync'd up through Sonatype will > deflect the "perception" that the project is stale i.e. 9 months since > its last release is no big deal... not having its latest release "out > there" where it can be *effortlessly consumed* *IS* IMO. > > 2)  Some process needs to be setup to allow others to get into the > ground floor as contributors.  This OSS at its best.  There are numerous > talented people on this list alone that not letting go of the keys WILL > kill Stripes.  Period.  As I personally have not led any OSS projects I > am not sure what the best procedure / process to follow is nor do I know > where to start but I'm sure others can chime in on how to properly > initiate this.  If this was truly difficult then OSS would not exist. > This is *CRITICAL*. > > 3)  All the other good initiatives that have been started need to > continue like setting up a new web site, a better place for forums > (mailing lists are wonderful but people search the web more often than > mailing lists for quick answers), deciding on how to partition > extensions, stacks, etc... (of course there is debate here), etc... > > But if 1) and 2) don't happen then yes not to sound dramatic Stripes > will surely die... not b/c it isn't a great product... but b/c people > like myself and others in the community will feel that they are beating > a dead horse in trying to get involved... and will simply give up and > look elsewhere.  If you alienate those that the "early adopters" / > "sneezers" then 3) won't matter at all. > > Ben, Freddy and / or Aaron... its time to step up to the plate... to if > anything hand over the keys and take on a reviewer / advisor role in the > future of this wonderful framework. > > Regards, > > --Nikolaos > > > Evan Leonard wrote: >> Nicolai, >> >> Absolutely. This is a must.  I am starting to use Stripes for a project and want to participate in the community. However, its not clear how to do so! >> >> Is it clear in the community how decisions are made about these things? Are there certain "core" developers with some level of authority? Forgive me as I'm just coming up to speed. >> >> Evan > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Stripes-users mailing list > Stripes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stripes-users ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- /Jeppe ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users -- /Jeppe

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users