struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <>
Subject Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
Date Sat, 25 Nov 2006 02:51:07 GMT
For the sake of documentation, I'll go ahead and take some of these (and 
Ted's) points regarding where to go upon graduation and post them to the 

Thanks everyone for your continued input. . .


Niall Pemberton wrote:
> If tiles can achieve the critical mass to become a TLP then IMO that
> would be the best solution - at this point it looks at least a couple
> of devs short of that. In the meantime its question of "where can it
> do its growing?". Commons makes less sense to me than staying here
> since theres definetly already a community here interested in Tiles -
> in Commons we don't know how interested the community would be and I
> doubt it would ever match here. Add to that the fact that the 3
> interested developers are already Struts developers - but not Commons
> developers and the fact that tiles resources (repository & bugs) are
> already here staying here for the time being looks like the best
> option.
> I can only think of reasons why it would be better for tiles to remain
> in Struts rather than Commons. If there is a case for moving tiles to
> Commons, then its yet to be made for me.
> Making it a Struts2 sub-project seems like a backward step - what
> would have been the point of emarking on a "standalone tiles" if the
> end result is for it to just move from being part of Struts1 to part
> of Strus2? Again if there are the benefits of doing this then they
> need to be laid out.
> I really can't see the point of making alternative suggestions without
> making the case for them. I can see benefts for tiles being
> (temporarily) a Struts sub-project....
> - theres an interested community here
> - the active developers are here
> - the other developers here all know what tiles is about (to varying 
> degrees)
> - theres a PMC that knows the software
> ...and unless someone else makes a better case for an alternative then
> thats the best option IMO
> Niall
> On 11/24/06, Ted Husted <> wrote:
>> When we invented the Commons, it was not our intention to exclude "web
>> components". If we had even suggested such a thing, I doubt that the
>> Jakarta PMC would have approved our proposal. At the time, we took the
>> notion that ASF projects were suppose to be tied to HTTPD very
>> seriously. Of course, since then, we added many top-level projects
>> that have little to do with HTTPD. But, that shouldn't mean web
>> components have suddenly become second-class citizens. I believe that
>> the phrase "server-related" in the charter is meant to include web
>> servers.
>> Unless and until the Jakarta Commons PMC rejects a proposal from the
>> Tiles group, I consider it to be a valid alternative to be explored,
>> and until it's been fully explored, I will consider the proposal to
>> create a Struts Tiles subproject premature.
>> Others may think differently, but I am entitled (and even obliged) to
>> define what it is required to obtain my vote. (The vote need not be
>> unanimous, but only a 3/4 majority of the PMC.)
>> As it stands, the ASF's preferred unit of release is the TLP. If the
>> Tiles group is not ready to become a TLP, and unwilling to even try
>> and join the Commons, then I would suggest that Tiles is not ready to
>> "graduate".
>> A third alternative (aside from an independant project) would be to
>> bring Tiles back into the Struts 2 subproject as part of the Tiles
>> plugin. If other projects want to use Tiles, they could just grab the
>> tiles-plugin.jar and import the appropriate packages. Rather than fuss
>> with a separate project or subproject, we could document how to use
>> the Tiles JAR outside of the Struts 2 environment.
>> If volunteers from other projects begin to contribute to Tiles, and
>> want to *build* Tiles without importing the s2 core, then the Tiles
>> group could then apply for TLP status, either to the board or though
>> the Incubator. In the meantime, we could continue to handle Tiles
>> matters on the mailing lists, just as we would for any plugin (or
>> subproject).
>> In any event, if it would be helpful, I see no reason why we can't
>> create tagged builds of Tiles. A build is not a release, regardless of
>> whether we call it a "nightly", "snapshot", or "test".
>> -Ted.
>> On 11/23/06, Martin Cooper <> wrote:
>> > On 11/23/06, Ted Husted <> wrote:
>> > >
>> > > I'd like to see the proposal discuss the alternatives to becoming a
>> > > Struts subproject. A good role for a proposal is to summarize various
>> > > threads. Becoming a subproject seems to be a foregone conclusion of
>> > > the proposal, with no discussion of the alternatives.
>> >
>> >
>> > Well, yeah, that's what is being _proposed_. We did discuss the 
>> options on
>> > the mailing list, more than once, and came to the conclusion that 
>> becoming a
>> > Struts sub-project was the right interim step. I don't see that we 
>> need to
>> > have the discussion all over again just because the proposal has 
>> been put on
>> > the wiki.
>> >
>> > In previous threads, Jakarta was mentioned, but not so much the
>> > > Jakarta Commons. Why is it that we are not proposing to move Tiles to
>> > > the Commons, as we did with the Validator, and others?
>> >
>> >
>> > Sigh. We've had this discussion _lots_ of times already, and we've had
>> > similar discussions over in Commons. Jakarta Commons is not about web
>> > components, and people do not want it to be about web components, 
>> which is
>> > why the notion of Jakarta Web Components has been bandied about so 
>> much.
>> > Validator makes sense in Commons because it's not tied to the web; 
>> the part
>> > that does tie to the web is in Struts, not Validator. I, for one, 
>> would not
>> > want to propose Tiles as a Commons component, because I'm almost 
>> certain it
>> > would be rejected, and because I would vote against that myself.
>> >
>> > Also, Tiles might be able to become a TLP by resolution of the board.
>> > > The situation is not much different than Shale. The incubator is
>> > > charged with "acceptance and oversight of new products submitted or
>> > > proposed to become part of the Foundation". Tiles is already part of
>> > > the foundation.
>> >
>> >
>> > Yes, Tiles might be able to become a TLP, but it is my perception 
>> that the
>> > people involved are not ready for that. It behooves us to provide 
>> better
>> > options than either staying in the sandbox or going straight to TLP. 
>> That
>> > you bring up Shale is interesting; note that we went through exactly 
>> the
>> > same process with Shale as we are now proposing for Tiles. Shale 
>> went from
>> > the sandbox to a Struts sub-project first. Only later, once it found 
>> its
>> > feet as a sub-project, did it go off to TLP land.
>> >
>> > Speaking of the Incubator, we might also note that Incubator podlings
>> > > do have releases.
>> > >
>> > > Even without quantifying it as a "release", given the usual release
>> > > plan, Tiles could still create a tagged test-build. Before deciding
>> > > whether Tiles should be a subproject or not, I think I'd like to see
>> > > the volunteers create a test-build that could be a release if the PMC
>> > > gave the nod.
>> >
>> >
>> > Why would we introduce a new rule for Tiles that we have never 
>> imposed on
>> > other projects coming out of the sandbox?
>> >
>> > Moving a code branch out the sandbox is a trivial task. What's not
>> > > trivial is doing everything that's needed to turn a snapshot into a
>> > > potential release.
>> >
>> >
>> > True. But that has never before been tied to promoting something out 
>> of the
>> > sandbox, and I don't think that introducing it in the midst of a 
>> proposal,
>> > after most of the discussion has already happened on the lists, is a
>> > productive thing to do.
>> >
>> > --
>> > Martin Cooper
>> >
>> >
>> > -Ted.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message