struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: [tiles2] Tiles TLP and Dimensions incubation
Date Fri, 01 Dec 2006 16:49:39 GMT
On 12/1/06, Antonio Petrelli <apetrelli@apache.org> wrote:
>
> Martin Cooper ha scritto:
> > On 12/1/06, Antonio Petrelli <apetrelli@apache.org> wrote:
> >>
> >> Craig McClanahan ha scritto:
> >> > The Dimensions code is going to have to go through
> >> > the Incubator -- even though its likely that this can go very
> quickly,
> >> > there
> >> > is no reason to mess up the progress of the Tiles TLP proposal by
> >> > trying to
> >> > do them together.
> >>
> >> Hi Craig, when I wrote "at the same time" I did not mean "together".
> >> Since probably Dimensions will become a subproject of Tiles TLP
> > If Dimensions would ultimately be merged into Tiles, that is one
> > thing, and
> > that might be fine. If, however, you are thinking that Dimensions
> > would live
> > as a "similar concept but separate framework" to Tiles, but within the
> > same
> > TLP, that is quite another thing, and not something I would like to
> > see, not
> > to mention the ASF Board.
>
> I see. In this case Dimensions does not exist without Tiles: maybe the
> concept of "subproject" is wrong, it should be considered literally an
> extension (it contains a lot of classes that extend Tiles ones), or a
> component.
> Is the concept of "component" or "extension" incompatible with possible
> incubation into Tiles TLP?


No. If it would be a component of Tiles or an extension to it, that would be
a natural fit and would be fine. But I think we've all agreed now that we
should table this discussion until a Tiles TLP is up and running. :-)

--
Martin Cooper


Thanks
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message