You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wendy Smoak <ja...@wendysmoak.com> on 2005/08/24 19:44:10 UTC
Standalone Tiles - JSP version & tld file
From: <gr...@intellicare.com> (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?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/25/05, David Geary <sa...@earthlink.net> wrote:
> Le 05-08-25 à 10:53, Craig McClanahan a écrit :
>
> > On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
> >
> >> On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
> >>
> >>> 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?
>
> Abstracting out the servlet API will break controllers because we're
> passing HttpServletRequest, HttpServletResponse, and ServletContext
> to the controller's perform and execute methods. Would we change
> those method signatures to take an external context instead?
Ideally, yes ... but note that changing the package name breaks
existing uses of Controller as well. It would seem reasonable for the
Struts integration layer to keep a copy of the old Controller
interface (under the old package name), so people could continue to
run -- but when the developer switches to the standalone Tiles version
of Controller they would have to migrate to the external context
thing.
If that's too harsh, we could probably have old-style and new-style
versions of Controller in standalone Tiles (so that the framework
would no which one to call), with the limitation that old-style
controllers would not work in portlets.
> david
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Ted Husted <te...@gmail.com>.
If you guys are ready to do the work, I'd say let's just do it, and we
can use Tiles subproject with Classic 1.3.x. We're shipping
subprojects in this release series, and we might as well just ship
them all and be done with it. Having two versions of Tiles is likely
to cause more confusion than the edge cases are worth. And, if we are
fixing other things along the way, anyone who might be within those
edge cases (if any) might be happy for the improvements.
I could refactor MailReader to use Tiles (rather than JSP:include) as
a simple test bed and resurrect/repair the Tiles demonstration
application, to exercise advanced features. As long as Tiles works the
same from the configuration-file layer, I'd say we're OK.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by David Geary <sa...@earthlink.net>.
Le 05-08-25 à 13:24, Craig McClanahan a écrit :
> On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
>
>> On Aug 25, 2005, at 1:55 PM, David Geary wrote:
>>
>>> I'm +1 for this, but should we make plugging standalone Tiles back
>>> into Struts
>>> a priority and tackle this once that's done? Perhaps it's unfounded,
>>> but I'm
>>> concerned that the current Tiles will change if we don't act
>>> quickly.
>>>
>>
>> If Tiles needs more changes wouldn't it be easier to implement them
>> while it's still in the Sandbox than when it becomes a sub-project or
>> whatever? Once something is published it will be more difficult to
>> change it. So, what are the changes? In addition to Craig's
>> idea of
>> externalizing the Servlet API I'd like to further refine the
>> ComponentDefinition class. xmlDefinition extends ComponentDefinition
>> and does some stuff that, it seems to me, should be moved up to the
>> base level. Possibly, the whole xmlDefinitiion package could go away
>> and be merged up. Right now I think it's a bit of a mess b/c I
>> merged
>> some of it up but not the rest. OTOH, that wouldn't affect users
>> unless they are subclassing DefinitionsFactory or
>> ComponentDefinitions
>> or something.
I doubt there are many folks who've done that, so I wouldn't be too
squeamish
about that refactoring. Others, of course, may disagree.
>> Either way, because Standalone Tiles has changed so much internally
>> from the integrated version we should probably be real careful about
>> how it's brought back in. I guess we could deprecate
>> org.apache.struts.tiles and bring in org.apache.tiles.
I'm not sure what that deprecation would entail. We'd have to make
sure that
everything in o.a.s.t gets rewired to work with standalone Tiles,
right? Perhaps
we could just yank o.a.s.t entirely and replace it with o.a.t. I
doubt that many
people reference o.a.s.t in their code, with the exception of
controllers.
Does anyone have a feel for what else it'd take to unplug the current
Tiles from
Struts and plug in standalone Tiles? I haven't mucked around in Struts
proper code for quite some time, so it's a mystery to me.
david
>>
>> Sorry, this is kinda random. As Craig said once, we have one shot at
>> changing things while Tiles is in the sandbox. I'd hate for us to
>> wrap
>> that up prematurely.
>
> Sandbox or subproject doesn't really make any difference on being able
> to refine APIs, until standalone Tiles does a 1.0 release. From that
> point on is where you'd want the APIs to be stable.
>
>
>> Greg
>>
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
> On Aug 25, 2005, at 1:55 PM, David Geary wrote:
> > I'm +1 for this, but should we make plugging standalone Tiles back
> > into Struts
> > a priority and tackle this once that's done? Perhaps it's unfounded,
> > but I'm
> > concerned that the current Tiles will change if we don't act quickly.
>
> If Tiles needs more changes wouldn't it be easier to implement them
> while it's still in the Sandbox than when it becomes a sub-project or
> whatever? Once something is published it will be more difficult to
> change it. So, what are the changes? In addition to Craig's idea of
> externalizing the Servlet API I'd like to further refine the
> ComponentDefinition class. xmlDefinition extends ComponentDefinition
> and does some stuff that, it seems to me, should be moved up to the
> base level. Possibly, the whole xmlDefinitiion package could go away
> and be merged up. Right now I think it's a bit of a mess b/c I merged
> some of it up but not the rest. OTOH, that wouldn't affect users
> unless they are subclassing DefinitionsFactory or ComponentDefinitions
> or something.
>
> Either way, because Standalone Tiles has changed so much internally
> from the integrated version we should probably be real careful about
> how it's brought back in. I guess we could deprecate
> org.apache.struts.tiles and bring in org.apache.tiles.
>
> Sorry, this is kinda random. As Craig said once, we have one shot at
> changing things while Tiles is in the sandbox. I'd hate for us to wrap
> that up prematurely.
>
Sandbox or subproject doesn't really make any difference on being able
to refine APIs, until standalone Tiles does a 1.0 release. From that
point on is where you'd want the APIs to be stable.
> Greg
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Greg Reddin <gr...@fnf.com>.
On Aug 25, 2005, at 1:55 PM, David Geary wrote:
> I'm +1 for this, but should we make plugging standalone Tiles back
> into Struts
> a priority and tackle this once that's done? Perhaps it's unfounded,
> but I'm
> concerned that the current Tiles will change if we don't act quickly.
If Tiles needs more changes wouldn't it be easier to implement them
while it's still in the Sandbox than when it becomes a sub-project or
whatever? Once something is published it will be more difficult to
change it. So, what are the changes? In addition to Craig's idea of
externalizing the Servlet API I'd like to further refine the
ComponentDefinition class. xmlDefinition extends ComponentDefinition
and does some stuff that, it seems to me, should be moved up to the
base level. Possibly, the whole xmlDefinitiion package could go away
and be merged up. Right now I think it's a bit of a mess b/c I merged
some of it up but not the rest. OTOH, that wouldn't affect users
unless they are subclassing DefinitionsFactory or ComponentDefinitions
or something.
Either way, because Standalone Tiles has changed so much internally
from the integrated version we should probably be real careful about
how it's brought back in. I guess we could deprecate
org.apache.struts.tiles and bring in org.apache.tiles.
Sorry, this is kinda random. As Craig said once, we have one shot at
changing things while Tiles is in the sandbox. I'd hate for us to wrap
that up prematurely.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by David Geary <sa...@earthlink.net>.
Le 05-08-25 à 10:53, Craig McClanahan a écrit :
> On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
>
>> On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
>>
>>> 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?
Abstracting out the servlet API will break controllers because we're
passing HttpServletRequest, HttpServletResponse, and ServletContext
to the controller's perform and execute methods. Would we change
those method signatures to take an external context instead?
>>>
>>> If we're ever going to do this to standalone Tiles, pre-1.0 would
>>> seem
>>> like the right time.
>>>
>>
>> I agree with that. My refactoring job pushed it up to the level of
>> TilesUtil. Are you saying we should take it out of TilesUtil also?
>
> It's not just TilesUtil (your refactoring narrowed the amount of work
> needed, though). A large number of the method signatures throughout
> Tiles take a ServletContext, HttpServletRequest, or
> HttpServletResponse parameter. None of that will work in a portlet
> environment (which provides
> PortletContext/PortletRequest/PortletResponse APIs) without bridging
> layers to adapt backwards.
>
> The way JSF approached this was to define an ExternalContext API that
> abstracted away the differences. I'd propose to do something like
> that for standalone Tiles, and pass such a context object around,
> instead of the individual servlet API dependent objects.
I'm +1 for this, but should we make plugging standalone Tiles back
into Struts
a priority and tackle this once that's done? Perhaps it's unfounded,
but I'm
concerned that the current Tiles will change if we don't act quickly.
david
>
> Craig
>
>
>> Greg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
> On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
>
> > 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?
> >
> > If we're ever going to do this to standalone Tiles, pre-1.0 would seem
> > like the right time.
>
> I agree with that. My refactoring job pushed it up to the level of
> TilesUtil. Are you saying we should take it out of TilesUtil also?
>
It's not just TilesUtil (your refactoring narrowed the amount of work
needed, though). A large number of the method signatures throughout
Tiles take a ServletContext, HttpServletRequest, or
HttpServletResponse parameter. None of that will work in a portlet
environment (which provides
PortletContext/PortletRequest/PortletResponse APIs) without bridging
layers to adapt backwards.
The way JSF approached this was to define an ExternalContext API that
abstracted away the differences. I'd propose to do something like
that for standalone Tiles, and pass such a context object around,
instead of the individual servlet API dependent objects.
Craig
> Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Greg Reddin <gr...@fnf.com>.
On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
> 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?
>
> If we're ever going to do this to standalone Tiles, pre-1.0 would seem
> like the right time.
I agree with that. My refactoring job pushed it up to the level of
TilesUtil. Are you saying we should take it out of TilesUtil also?
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/25/05, James Mitchell <jm...@apache.org> 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: jmitchell@apache.org
> Skype: jmitchtx
>
>
>
> On Aug 25, 2005, at 1:44 AM, Martin Cooper wrote:
>
> > On 8/24/05, Craig McClanahan <cr...@gmail.com> wrote:
> >
> >> On 8/24/05, James Mitchell <jm...@apache.org> 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: jmitchell@apache.org
> >>> Skype: jmitchtx
> >>>
> >>>
> >>>
> >>> On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
> >>>
> >>>
> >>>> On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> >>>>>
> >>>>>
> >>>>>> From: <gr...@intellicare.com> (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: dev-unsubscribe@struts.apache.org
> >>>>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> ---
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by James Mitchell <jm...@apache.org>.
+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?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
On Aug 25, 2005, at 1:44 AM, Martin Cooper wrote:
> On 8/24/05, Craig McClanahan <cr...@gmail.com> wrote:
>
>> On 8/24/05, James Mitchell <jm...@apache.org> 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: jmitchell@apache.org
>>> Skype: jmitchtx
>>>
>>>
>>>
>>> On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
>>>
>>>
>>>> On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
>>>>
>>>>
>>>>> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>>>>>
>>>>>
>>>>>> From: <gr...@intellicare.com> (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: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Ted Husted <te...@gmail.com>.
On 8/25/05, Martin Cooper <mf...@gmail.com> wrote:
> 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.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Martin Cooper <mf...@gmail.com>.
On 8/24/05, Craig McClanahan <cr...@gmail.com> wrote:
> On 8/24/05, James Mitchell <jm...@apache.org> 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: jmitchell@apache.org
> > Skype: jmitchtx
> >
> >
> >
> > On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
> >
> > > On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
> > >
> > >> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > >>
> > >>> From: <gr...@intellicare.com> (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: dev-unsubscribe@struts.apache.org
> > >>> For additional commands, e-mail: dev-help@struts.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > >> For additional commands, e-mail: dev-help@struts.apache.org
> > >>
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/24/05, James Mitchell <jm...@apache.org> 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.
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?
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: jmitchell@apache.org
> Skype: jmitchtx
>
>
>
> On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
>
> > On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
> >
> >> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> >>
> >>> From: <gr...@intellicare.com> (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: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by James Mitchell <jm...@apache.org>.
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?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
> On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
>
>> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>>
>>> From: <gr...@intellicare.com> (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: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Craig McClanahan" <cr...@gmail.com>
On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
>> 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.
The build files have been changed to Servlet 2.3/JSP 1.2.
Looking at the URI again, I assume http://jakarta.apache.org/tiles *is* the
correct one, since the URI in the doc/userGuide file still has 'struts', and
there is nothing in build.xml that's generating the tld from the userGuide.
I'll get the documentation into tiles-core.tld before deleting the old
doc/userGuide/struts-tiles.xml and associated stylesheet, so that one day
Maven can build the Tiles website.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > From: <gr...@intellicare.com> (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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Martin Cooper <mf...@gmail.com>.
On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: <gr...@intellicare.com> (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.
--
Martin Cooper
> --
> Wendy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org