Hi Will, folks,
> That said, I don't agree with the plugins concept at all.
To be honest, I also think a clean dependency mechanism + some centralized
docs would be enough.
Anyway, it's a nice to have, as it allows beginners to have no ramp up.
Simply list plugins, install them, it adds the deps, classes and updates
your web.xml.
Even if many Stripers won't probably use it once they are used to the
framerwork, consider it a selling feature.
> 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."
Well, everything is subjective, but clearly some of the "extensions" will be
first class citizens. Think about what's already in the core and will be
moved (e.g. Spring integration). Now, I've never said that ALL extensions
should be included to the main repo and built along with the framework. I
think every extension, once it gets popular, stable etc., turns into a good
candidate for integration into the "offficial" extensions of the framework.
> There's also the issue of code segregation, IP rights, and commit access.
Yep, but on the other hand it ensures that all parts are consistent when new
versions are released, that they have the same license, and that they are
managed by the same group of developers. Last, it could drag new coders into
the framework. And again, it doesn't mean that evey extension has to be
there, just the ones that have been approved by the community. You can still
write your separate, third party extension if you want, and distribute it
the way you want.
In short, think about how life would be if Spring's codebase contained only
core container, and everything else (JDBC, JMS, ...) was scattered around
the web... Different builds, different policies of maven sync, different
websites... admin drag you said ?
:P
That's the way all projects handle scalability of the codebase : they split
stuff into modules.
I guess Stripes is now at that point, and it's a good sign.
> There's no reason to repaint the whole thing or re-engineer it from the
ground up [...]
Not sure you talk about the modularization of the build here.
If you do, c'mon... the build already exists, there's nothing to do. I'd say
half a day work, not a class file touched, only a few moves...
>From the ground up ???
> There's always stuff to do. Leverage the processes in place [...]
That's exactly what I'm trying to do :)
Cheers
Remi
2011/4/20 Will Hartung <redro...@sbcglobal.net>
> 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
>
------------------------------------------------------------------------------
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
