I'm not going to copy the entire thread, and I'm not responding to any one in particular.
Not being a maven fan, even I can agree with the conversion to Maven. The primary reason is that Maven has become a de facto portable project meta data that all of the IDEs support well, and makes IDE integration reasonably simple. The secondary reason is that someone has gracefully volunteered to undertake the entire process finishing and rounding out the process, and once complete, the ongoing maintenance should be minor and simple to keep up, at least until Maven 4 comes out and they break backward compatibility Yet Again. That said, I don't agree with the plugins concept at all. Stripes is already pretty plugin friendly and whatever burden there is in terms of creating an add on to Stripes is likely minor compared to the work on the add on functionality itself. I don't think folks are saying "yea, I'd like to add that to Stripes, but it's just Too Hard". Implementing an interface and adding a line or two to web.xml -- not really arduous. Even I have done it, and if you know anything about my history with Stripes, that's saying something. I see no motivation to make Stripes a plugin framework with some default modules. It's that already, effectively. It's just that this concept doesn't boil to the top when it comes to implementing Stripes. It pretty much works out of the box with minimal configuration. That's a feature. In contrast to something like Spring or JBoss, which is all modules of all kinds and all generic metadata that you have to master to get "Hello World" running. It's a mostly terrible experience, especially for a new person. I also don't agree with moving the popular Stripes Stuff in to the Stripes source tree. If those are included then, regardless of original intent, users will think that these are "first class" citizens of Stripes, and that the there is some obligation for the maintainer of Stripes core to maintain these as well. Basically that makes this "free code for stripes", but it's free as in "free like a puppy". Ben has enough to do just to keep up with bug fixes and such without adding traffic and questions and clutter to the core system stuff that he's not going to be responsible for. There's also the issue of code segregation, IP rights, and commit access. Since each module would, ostensibly, have a different owner and it's easy to see how rights will be different for different people in different parts of the source tree. More bookkeeping, more admin drag, less stuff done to Stripes core. If there is a desire that these projects have more visibility on the web site and wiki, then absolutely. Ask for wiki write access and start linking away and pointing to the assorted projects in their own homes. Perhaps the maintainers of StripesStuff can be more liberal, grant more rights to folks that want to host their project there, and let that be more of a Wild West for, well, Stripe Stuff. Maybe not. But in the end, it doesn't really matter because with an email, wiki rights are pretty easy to get if you want to highlight you favorite project, hosted where you want to host it. As for the GIt conversion, I don't get it. We're not the Linux kernel. There aren't zillions of patches pending to be applied every day. In fact, there are pretty much zero patches. If folks want to make changes, and make a difference, then make or find an issue on Jira, and submit a patch. There's nothing in the toolset holding that up. When Ben throws up the white flag because of the crushing load of source patches coming in to core instead of just chatter on the ML, then maybe there's motivation to change to something like Git. If you'd like to contribute to anything, then do so. There's no reason to repaint the whole thing or re-engineer it from the ground up just to contribute. Stripes has a gazillion extensibility points. If Stripes isn't extensible in a place you think it should be, bring it up, add a Jira, and come up with a potential solution. Those are the kinds of changes that need to go in to Stripes core. Changes to make it easier for folks to do the stuff they want. There's always stuff to do. Leverage the processes in place, and when they're exercised more, then we'll have more data to apply towards other changes. But right now, there's really not a lot of data. Lots of chatter, but no real data. So use the system and share your experiences with it. Regards, Will Hartung ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
