Hi guys,
Again, I totally agree with Will about the plugins strategy and about
including them in Stripes source tree.
That's why I've suggested GitHub. I believe it can handle what we are trying
to achieve here.
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.
>
This is not a valid argument to me. I don't think that the amount of patches
submitted is a decisive factor, it's all about organization.
Lately, I've been working a lot with
ShrinkWrap<https://github.com/shrinkwrap/shrinkwrap>and
Arquillian <https://github.com/arquillian/arquillian> from JBoss. It were
those two projects that made me move to and started loving GitHub, I've even
start to commit code into ShrinkWrap so easy it was.
Now, take a look at ShrinkWrap organization <https://github.com/shrinkwrap/>,
it's exactly what we are trying to achieve here. A central place to have a
project and its sub-projects or extensions. And plugins don't need to be (or
must not be) on the Core project source code tree.
Each plugin is maintained by its creator, not the core team. Have its
developer lose interest and stop updating it, we can easily fork the project
under Stripes organization and continue evolving it to remain compatible
with later Stripes versions.
I'm not a GitHub guru nor even an advanced user, but I believe it is a
better solution than the one we have now and can fix the majority of the
issues we are discussing here. Some people have brought it to discussion in
this mailing list long before me, not sure why we haven't heard anything
from them since then...
If your problem is about using Git, don't worry, GitHub also supports
Subversion <https://github.com/blog/644-subversion-write-support>.
I will not continue to argue about GitHub if no one, apart from me, sees the
advantages in using it, but please think about it for a second before
shooting arguments like the one I quoted above.
Cheers,
--
Samuel Santos
http://www.samaxes.com/
On Wed, Apr 20, 2011 at 10:09 AM, VANKEISBELCK Remi <r...@rvkb.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
