On 4/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: > On 4/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > Do we need to be discussing this now? I kinda feel like this should > > wait until Tiles is ready to stand alone. > > In another thread, Don pointed out that we need to be more forthcoming > with the project's roadmap. Right now, the Tiles roadmap is not clear > to me. I thought our intention was to propose it as a subproject, but > people have gradually come to speak of it as a Struts subproject.
Well, at least being a subproject is an improvement over being just another package in the struts.jar. > > If there is sufficient interest/support from developers, then i don't > > see any problem with having Tiles be a top level project. But to be > > honest, i don't think we have that at this, or if we do, then it is a > > surprise to me. And i'll point the finger at myself on that one too. > > The time i have available for open source work is very limited lately > > and Velocity is my priority there. I'd like to jump in and help with > > Tiles, but the time isn't there. > > We need the same level of support for Tiles regardless of whether it > is TLP or a subproject. cool. i didn't know the ASF was down with three developer TLPs. makes sense, i guess. it just seems a little more useful to embed such small communities in a somewhat larger one, so that there is more oversight, cross pollination, and especially more exposure to new potential participants. > If Tiles has become a one-developer show, then > we have deeper problems that we need to fix now. What would those be and how would you fix them? Projects with a limited and relatively small scope naturally mature to a "good enough" status where most developers fall back to just being users. So long as the users are happy, I call that a success story, not a sign of deeper problems. It feels to me like the only big "itch" with Tiles these days is that it has been stuck in struts-1.x-jars. If just one person has the right combo of time and motivation to scratch an itch like that and no other developers are rushing to help, that's no big deal to me. I still think that's pretty normal for a project like Tiles, not a sign of deeper problems. > > Right now, it is easier for me to envision Tiles staying on as a > > Struts subproject. As for jumping over to Jakarta, that wouldn't > > bother me, but i'm not sure i understand why. Just because it's not a > > full framework on the level of Struts 1.x, Shale, and SAF 2? That's > > not a reason that motivates me a lot. > > Shale does for JSF what Action does for JSP, and I believe it make > sense to develop it here. Eventually, we may find a way to merge > Action and Shale back together again, but for now, no one has figured > out a way to do that. But, we may yet. i.e. Struts is pretty much an umbrella right now, but you hope it won't always be. Well, let them who do the work make the decision. If people are wiling to work to move Tiles fully out of Struts as a step toward fulfilling that hope, that's cool with me. > Standalone Tiles is not dependant on either Shale or Action. Tiles is > a component that they both *can* use, the same way they both use > BeanUtils. When we extracted all the other components, we gave them > lives of their own in the Commons. We should pay Tiles the same > courtesy. Back then, Struts wasn't a TLP with its own disconnected set of frameworks, and you didn't given them lonely TLP lives. BeanUtils and friends got to hang out in the well-populated-with-various-developers Jakarta Commons I do wish Tiles had gotten that treatment back then. Anyway, since i have no time to offer either way and really should be hammering out some paid-work code rather than writing this email, i will (for now) bow out of this discussion and let them that do the work make the call. :) > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
