Hi Will and others
It seems we're discussing two different things in this thread.
1) Maven / ant for building stripes core. Stripes must as it is now be
available in a Maven repository. How it gets in there doesn't really matter
2) Plugin technology:
Regarding the plugins - let's just revisit the reasons for discussing it:
- Systems like Grails have a vibrant plugin environment with hundreds of
plugins - making Grails look much more alive than Stripes. The grails plugin
technology includes view unlike Stripes that's a Java - alone plugin
technology.
We all like Stripes for it's simplicity of use. Adding a plugin strategy to
it might just give it the share of the fame needed to keep it alive in the
mindset of the people that takes decisions (Managers, Architects etc.)
Adding a plugin strategy should be kept away from the development of the
Stripes core for the reasons Will states above and maybe that's exactly
where we'll have end this discussion - that the Stripes plugin idea is a
completely separate project from Stripes core.
Our conclusions so far could be:
- Stripes core is handled brilliantly by the people and with the technology
they choose. No real need to interfere with that!
- Stripes could use a better plugin strategy including handling of view
parts of the plugins.
What do you say - could that be the conclusion?
Regards
Morten
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
>
--
Morten Matras
Consultant
Blob Communication ApS
Svendsagervej 42
DK-5240 Odense NØ
P: (+45) 36 96 07 06
W: www.blobcom.com
E: morten.mat...@gmail.com
------------------------------------------------------------------------------
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
