On 8/25/05, James Mitchell <[EMAIL PROTECTED]> wrote: > +1 > > That's pretty much my experience too. > > So, with that said, can we move standalone to subproject level or are > we waiting on something? >
One interesting wrinkle is that "Integrated Tiles" (the version that has org.apache.struts.tiles package names) currently occupies the "tiles" directory name at the subproject level. It would likely make sense to migrate (svn move) that to some other directory name, and adjust the Struts Classic build processes, before moving "Standalone Tiles" up a level. Craig > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > Yahoo: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > > > On Aug 25, 2005, at 1:44 AM, Martin Cooper wrote: > > > On 8/24/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > >> On 8/24/05, James Mitchell <[EMAIL PROTECTED]> wrote: > >> > >>> Sorry if I'm piping up late on this. > >>> > >>> What's the plans for Tiles? Will we support embedded tiles or will > >>> we simply adapt standalone to work as we do for the commons stuff? > >>> > >>> > >> > >> That's definitely a call for the developers invested in 1.3.x, but it > >> certainly makes the most sense to have one and only one > >> implementation > >> around, and just do bindings to it. Such bindings should be very > >> easy > >> in this case. > >> > > > > My preference would definitely be to support only one version, with > > that version being the one we expect to support in future releases. > > So, +1 for supporting Standalone Tiles only. > > > > > >> However, I've got a separate / semi-related question. Given that > >> we're changing package names anyway, it would be really cool to > >> abstract away the servlet API specific calling sequences, so that > >> standalone Tiles could work equally comfortably in a portlet > >> environment (without needing any portlet->servlet bridgework). The > >> only API a typical Tiles user will be using is Controller, so this > >> shouldn't be a huge deal. What do you think? > >> > > > > I'd say go for it. I would be *very* surprised if any more than a tiny > > minority of Tiles users have any dependency on the Tiles API at all. > > In my experience, the vast majority of Tiles users know little more > > than they need to know to define their tiles in the tiles-defs.xml > > file. > > > > -- > > Martin Cooper > > > > > > > >> If we're ever going to do this to standalone Tiles, pre-1.0 would > >> seem > >> like the right time. > >> > >> Craig > >> > >> > >>> > >>> -- > >>> James Mitchell > >>> Software Engineer / Open Source Evangelist > >>> Consulting / Mentoring / Freelance > >>> EdgeTech, Inc. > >>> http://www.edgetechservices.net/ > >>> 678.910.8017 > >>> AIM: jmitchtx > >>> Yahoo: jmitchtx > >>> MSN: [EMAIL PROTECTED] > >>> Skype: jmitchtx > >>> > >>> > >>> > >>> On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote: > >>> > >>> > >>>> On 8/24/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> On 8/24/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>> > >>>>>> From: <[EMAIL PROTECTED]> (on struts-user) > >>>>>> > >>>>>> > >>>>>>> test.jsp has this: > >>>>>>> <%@ taglib uri="http://jakarta.apache.org/tiles"; > >>>>>>> prefix="tiles" %> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> Jakarta? That can't be right... there's a problem: > >>>>>> > >>>>>> The tld in last night's tiles-core.jar has a JSP 1.1 tld with > >>>>>> that uri, > >>>>>> which is coming from src/conf. > >>>>>> > >>>>>> I noticed that tld the other day when I was changing the Maven > >>>>>> build files. > >>>>>> The doc/userGuide/tiles-core.xml file does have the right uri. I > >>>>>> think the > >>>>>> one in src/conf needs to be deleted-- the tld is probably still > >>>>>> supposed to > >>>>>> be generated from the files under doc/userGuide and doc/ > >>>>>> stylesheets as part > >>>>>> of the build. > >>>>>> > >>>>>> Eventually I'll generate a complete tld with all the > >>>>>> documentation, so that > >>>>>> Maven can create the taglibdoc and tag reference pages... the > >>>>>> one in > >>>>>> src/conf doesn't have any of that. > >>>>>> > >>>>>> And what JSP version is Standalone Tiles using? The build files > >>>>>> declare a > >>>>>> dependency on Servlet 2.4 and JSP 2.0. I thought the intent was > >>>>>> for Struts > >>>>>> Classic (which is now at Servlet 2.3) to move to Standalone > >>>>>> Tiles. Is that > >>>>>> going to be possible with the mismatch in dependencies? > >>>>>> > >>>>>> > >>>>> > >>>>> I believe the intent was that Standalone Tiles should rely on > >>>>> Servlets > >>>>> 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the > >>>>> case, > >>>>> and that we just need to fix up Tiles to conform to that. > >>>>> > >>>>> > >>>>> > >>>> > >>>> Yes, that was definitely the intent for Standalone Tiles. It > >>>> probably > >>>> got mixed up during the multiple iterations of cut-n-paste from the > >>>> Struts-embedded sources, plus cut-n-paste changes to the build > >>>> environment, plus ... > >>>> > >>>> Craig > >>>> > >>>> > >>>> > >>>>> -- > >>>>> Martin Cooper > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -- > >>>>>> Wendy > >>>>>> > >>>>>> > >>>>>> ----------------------------------------------------------------- > >>>>>> --- > >>>>>> - > >>>>>> 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] > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> 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] > >>> > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > > > --------------------------------------------------------------------- > 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]
