Re: Standalone Tiles as TLP
On 4/24/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > > > Agreed. Would it be possible to do this by JavaOne? Moving Tiles > isn't > > > a huge deal, but it would make the new directions of Struts easier to > > > explain to users. > > > > > > Hmm, JavaOne is only 3 weeks away... > > > > There are two things that would need to happen: > > > > 1) Get Standalone Tiles really standalone, so that there are no > dependencies > > on other Struts code. Maybe that's happened already - I've kinda lost > track. > > > > 2) Get Jakarta Web Components bootstrapped. Actually, I think moving > Tiles > > there might be just the kickstart that will get that subproject off the > > ground, because it would sidestep all the Commons navel-gazing that has > > effectively blocked its creation so far. > > > > I know Hen is on this list. Hen, any thoughts here before I propose this > on > > [EMAIL PROTECTED] > > +1'd this on IM :) Seems like a good idea for all concerned. I just sent the proposal to [EMAIL PROTECTED], so we'll see what happens. Feel free to join in the fun! ;-) -- Martin Cooper I'm also +1 to the struts-tiles being in Struts, not Tiles. > > Hen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Standalone Tiles as TLP
On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > Agreed. Would it be possible to do this by JavaOne? Moving Tiles isn't > > a huge deal, but it would make the new directions of Struts easier to > > explain to users. > > > Hmm, JavaOne is only 3 weeks away... > > There are two things that would need to happen: > > 1) Get Standalone Tiles really standalone, so that there are no dependencies > on other Struts code. Maybe that's happened already - I've kinda lost track. > > 2) Get Jakarta Web Components bootstrapped. Actually, I think moving Tiles > there might be just the kickstart that will get that subproject off the > ground, because it would sidestep all the Commons navel-gazing that has > effectively blocked its creation so far. > > I know Hen is on this list. Hen, any thoughts here before I propose this on > [EMAIL PROTECTED] +1'd this on IM :) Seems like a good idea for all concerned. I'm also +1 to the struts-tiles being in Struts, not Tiles. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
My time is very limited today so I'll respond quickly. 1) I want to get Tiles as close to a release as possible by J1, but it's a daunting task. The only huge effort is factoring out dependencies on the Servlet API, then testing. 2) I'm cool with joint up with the Jakarta Web Components, even though I don't have very much experience with it. If it provides more people who are interested in continuing Tiles, it can't be a bad thing. 3) I prefer the approach of other frameworks providing their own hooks into Tiles as opposed to the other way round. If Tiles provides the hooks, then it has to depend on all those frameworks. I'll try really hard to find some time this week to put into the final refactoring efforts. Thanks, Greg On Apr 23, 2006, at 5:35 PM, Craig McClanahan wrote: On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: I would think it would be Tiles' responsibility to support deployment with Struts. In that view, Tiles would be its own project, yet part of it would depend on struts-action.jar to provide the Struts hooks. In the same way, they would provide Struts Action 2 hooks, if necessary. This is a tough one - for me, at least. Should an independent Tiles have glue code for Struts, or should it be Struts' responsibility to provide the glue? If we look at Velocity, the glue is over there, but we've also talked about it coming here. If we look at Validator, the glue is here. If we look at Chain, the servlet and portlet glue is over there. I've always thought it would be as Martin describes for Validator -- standalone Tiles would really be standalone, and each framework that wanted to utilize it would provide it's own glue to some particular version (s) of Standalone Tiles. That is what Shale already does with the standalone Tiles stuff -- for example, Shale integrates tiles into the standard JSF navigation mechanism. That's not something that it seems reasonable to impose on a "standalone" project. My preference, at least at this time, would be for the Struts / Tiles glue to stay here. That will help Standalone Tiles stand on its own feet, and especially help with the notion that it's now independent of Struts. Any perception - real or otherwise - that Tiles is tied to Struts will be detrimental to Tiles as an independent library. +1 -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
+1 Let's keep the Struts-Tiles code and Tiles-Velocity type code out of stand-alone tiles for the moment. I think a better time for moving those over would be once Tiles is established and released as an independent Jakarta Web Component. Personally, I doubt there would ever be a "right time" to put glue code like that in Tiles. It strikes me that the glue is more about the non-tiles side of thing (at least from what I recall when I wrote the struts-chain code to handle tiles forward destinations.) I'd argue that any code to make Struts work well with Tiles belongs in Struts projects (and the same for tiles-velocity probably, although I don't really know that code.) Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > I would think it would be Tiles' responsibility to support deployment > > with Struts. In that view, Tiles would be its own project, yet part of > > it would depend on struts-action.jar to provide the Struts hooks. In > > the same way, they would provide Struts Action 2 hooks, if necessary. > > > This is a tough one - for me, at least. Should an independent Tiles have > glue code for Struts, or should it be Struts' responsibility to provide the > glue? If we look at Velocity, the glue is over there, but we've also talked > about it coming here. If we look at Validator, the glue is here. If we look > at Chain, the servlet and portlet glue is over there. > > My preference, at least at this time, would be for the Struts / Tiles glue > to stay here. That will help Standalone Tiles stand on its own feet, and > especially help with the notion that it's now independent of Struts. Any > perception - real or otherwise - that Tiles is tied to Struts will be > detrimental to Tiles as an independent library. +1 Let's keep the Struts-Tiles code and Tiles-Velocity type code out of stand-alone tiles for the moment. I think a better time for moving those over would be once Tiles is established and released as an independent Jakarta Web Component. > -- > Martin Cooper > > > Don > > > > Wendy Smoak wrote: > > > On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > > >> Agreed. Would it be possible to do this by JavaOne? Moving Tiles > > isn't > > >> a huge deal, but it would make the new directions of Struts easier to > > >> explain to users. > > >> > > > > > > What happens to Struts Tiles, then? I'm not sure I understand why > > > we're holding Struts Tiles out of the Struts Action distribution. > > > > > > Won't there always be a struts-tiles.jar of some kind, whether it's > > > the current one with all the code, or a much lighter version that > > > works with Standalone Tiles? > > > > > > -- > > > 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]
Re: Standalone Tiles as TLP
On 4/23/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > 1) Get Standalone Tiles really standalone, so that there are no > dependencies > > on other Struts code. Maybe that's happened already - I've kinda lost > track. > > This seems to be done -- sandbox/tiles/pom.xml has no struts > dependencies listed. > > Speaking of build files, there are three sets. Who is using them, and > is there any interest in standardizing on one? (Maven 2, of course!) +1 for Maven 2. :-) -- Martin Cooper -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Standalone Tiles as TLP
Ah, gotcha... I guess I wasn't clear that there was two different entities called "Tiles". Thanks for clearing it up (both you and Don, I saw your post too). Frank Wendy Smoak wrote: On 4/23/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Doesn't that conflict with the idea of making Tiles a stand-alone TLP? No. This is Struts Tiles, not Standalone Tiles. Standalone Tiles is in the sandbox, and will have a life of its own. Struts Tiles is what most of us are using. Eventually (and I'm not too clear on this part) it will become a plugin or wrapper or something to let Struts Action work with Standalone Tiles. But it sounds to me like there will always be a 'struts-tiles.jar', so we might as well keep it as part of Struts Action. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > The end goal is a standalone Tiles in the Jakarta Web Commons project > (to be created), then Struts Action 1 would have a struts-tiles artifact > which makes it possible for Struts users to use this standalone Tiles. > Think of it how Struts Scripting works or Struts validator. In the > meantime, we'd put the Struts Tiles project, which isn't standalone, > back into Action until we can replace the core of it with a new > dependency on the new Standalone Tiles. > > Did I get that right? :) Yep. Except I think the target name is 'Jakarta Web Components'. -- Martin Cooper Don > > Frank W. Zammetti wrote: > > Doesn't that conflict with the idea of making Tiles a stand-alone TLP? > > > > Frank > > > > Don Brown wrote: > >> I'm fine with this solution, as long as my original concern of a > >> circular dependency is resolved. > >> > >> Don > >> > >> Wendy Smoak wrote: > >>> On 4/23/06, James Mitchell <[EMAIL PROTECTED]> wrote: > >>> > >>> > I'm in the same camp on this one. I think we (SAF1) should be > providing a plugin that provides Tiles integration. > > >>> > >>> In that case, should Struts Tiles be put back under Struts Action? > >>> > >>> -- > >>> 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] > >
Re: Standalone Tiles as TLP
On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > 1) Get Standalone Tiles really standalone, so that there are no dependencies > on other Struts code. Maybe that's happened already - I've kinda lost track. This seems to be done -- sandbox/tiles/pom.xml has no struts dependencies listed. Speaking of build files, there are three sets. Who is using them, and is there any interest in standardizing on one? (Maven 2, of course!) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
The end goal is a standalone Tiles in the Jakarta Web Commons project (to be created), then Struts Action 1 would have a struts-tiles artifact which makes it possible for Struts users to use this standalone Tiles. Think of it how Struts Scripting works or Struts validator. In the meantime, we'd put the Struts Tiles project, which isn't standalone, back into Action until we can replace the core of it with a new dependency on the new Standalone Tiles. Did I get that right? :) Don Frank W. Zammetti wrote: Doesn't that conflict with the idea of making Tiles a stand-alone TLP? Frank Don Brown wrote: I'm fine with this solution, as long as my original concern of a circular dependency is resolved. Don Wendy Smoak wrote: On 4/23/06, James Mitchell <[EMAIL PROTECTED]> wrote: I'm in the same camp on this one. I think we (SAF1) should be providing a plugin that provides Tiles integration. In that case, should Struts Tiles be put back under Struts Action? -- 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]
Re: Standalone Tiles as TLP
On 4/23/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Doesn't that conflict with the idea of making Tiles a stand-alone TLP? No. This is Struts Tiles, not Standalone Tiles. Standalone Tiles is in the sandbox, and will have a life of its own. Struts Tiles is what most of us are using. Eventually (and I'm not too clear on this part) it will become a plugin or wrapper or something to let Struts Action work with Standalone Tiles. But it sounds to me like there will always be a 'struts-tiles.jar', so we might as well keep it as part of Struts Action. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
Doesn't that conflict with the idea of making Tiles a stand-alone TLP? Frank Don Brown wrote: I'm fine with this solution, as long as my original concern of a circular dependency is resolved. Don Wendy Smoak wrote: On 4/23/06, James Mitchell <[EMAIL PROTECTED]> wrote: I'm in the same camp on this one. I think we (SAF1) should be providing a plugin that provides Tiles integration. In that case, should Struts Tiles be put back under Struts Action? -- 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] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
I'm fine with this solution, as long as my original concern of a circular dependency is resolved. Don Wendy Smoak wrote: On 4/23/06, James Mitchell <[EMAIL PROTECTED]> wrote: I'm in the same camp on this one. I think we (SAF1) should be providing a plugin that provides Tiles integration. In that case, should Struts Tiles be put back under Struts Action? -- 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]
Re: Standalone Tiles as TLP
On 4/23/06, James Mitchell <[EMAIL PROTECTED]> wrote: > I'm in the same camp on this one. I think we (SAF1) should be > providing a plugin that provides Tiles integration. In that case, should Struts Tiles be put back under Struts Action? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
I'm in the same camp on this one. I think we (SAF1) should be providing a plugin that provides Tiles integration. -- James Mitchell On Apr 23, 2006, at 6:35 PM, Craig McClanahan wrote: On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: I would think it would be Tiles' responsibility to support deployment with Struts. In that view, Tiles would be its own project, yet part of it would depend on struts-action.jar to provide the Struts hooks. In the same way, they would provide Struts Action 2 hooks, if necessary. This is a tough one - for me, at least. Should an independent Tiles have glue code for Struts, or should it be Struts' responsibility to provide the glue? If we look at Velocity, the glue is over there, but we've also talked about it coming here. If we look at Validator, the glue is here. If we look at Chain, the servlet and portlet glue is over there. I've always thought it would be as Martin describes for Validator -- standalone Tiles would really be standalone, and each framework that wanted to utilize it would provide it's own glue to some particular version (s) of Standalone Tiles. That is what Shale already does with the standalone Tiles stuff -- for example, Shale integrates tiles into the standard JSF navigation mechanism. That's not something that it seems reasonable to impose on a "standalone" project. My preference, at least at this time, would be for the Struts / Tiles glue to stay here. That will help Standalone Tiles stand on its own feet, and especially help with the notion that it's now independent of Struts. Any perception - real or otherwise - that Tiles is tied to Struts will be detrimental to Tiles as an independent library. +1 -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
On 4/23/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > I would think it would be Tiles' responsibility to support deployment > > with Struts. In that view, Tiles would be its own project, yet part of > > it would depend on struts-action.jar to provide the Struts hooks. In > > the same way, they would provide Struts Action 2 hooks, if necessary. > > > This is a tough one - for me, at least. Should an independent Tiles have > glue code for Struts, or should it be Struts' responsibility to provide > the > glue? If we look at Velocity, the glue is over there, but we've also > talked > about it coming here. If we look at Validator, the glue is here. If we > look > at Chain, the servlet and portlet glue is over there. I've always thought it would be as Martin describes for Validator -- standalone Tiles would really be standalone, and each framework that wanted to utilize it would provide it's own glue to some particular version(s) of Standalone Tiles. That is what Shale already does with the standalone Tiles stuff -- for example, Shale integrates tiles into the standard JSF navigation mechanism. That's not something that it seems reasonable to impose on a "standalone" project. My preference, at least at this time, would be for the Struts / Tiles glue > to stay here. That will help Standalone Tiles stand on its own feet, and > especially help with the notion that it's now independent of Struts. Any > perception - real or otherwise - that Tiles is tied to Struts will be > detrimental to Tiles as an independent library. +1 -- > Martin Cooper Craig
Re: Standalone Tiles as TLP
On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > I would think it would be Tiles' responsibility to support deployment > with Struts. In that view, Tiles would be its own project, yet part of > it would depend on struts-action.jar to provide the Struts hooks. In > the same way, they would provide Struts Action 2 hooks, if necessary. This is a tough one - for me, at least. Should an independent Tiles have glue code for Struts, or should it be Struts' responsibility to provide the glue? If we look at Velocity, the glue is over there, but we've also talked about it coming here. If we look at Validator, the glue is here. If we look at Chain, the servlet and portlet glue is over there. My preference, at least at this time, would be for the Struts / Tiles glue to stay here. That will help Standalone Tiles stand on its own feet, and especially help with the notion that it's now independent of Struts. Any perception - real or otherwise - that Tiles is tied to Struts will be detrimental to Tiles as an independent library. -- Martin Cooper Don > > Wendy Smoak wrote: > > On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > >> Agreed. Would it be possible to do this by JavaOne? Moving Tiles > isn't > >> a huge deal, but it would make the new directions of Struts easier to > >> explain to users. > >> > > > > What happens to Struts Tiles, then? I'm not sure I understand why > > we're holding Struts Tiles out of the Struts Action distribution. > > > > Won't there always be a struts-tiles.jar of some kind, whether it's > > the current one with all the code, or a much lighter version that > > works with Standalone Tiles? > > > > -- > > 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] > >
Re: Standalone Tiles as TLP
On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > > Agreed. Would it be possible to do this by JavaOne? Moving Tiles isn't > a huge deal, but it would make the new directions of Struts easier to > explain to users. Hmm, JavaOne is only 3 weeks away... There are two things that would need to happen: 1) Get Standalone Tiles really standalone, so that there are no dependencies on other Struts code. Maybe that's happened already - I've kinda lost track. 2) Get Jakarta Web Components bootstrapped. Actually, I think moving Tiles there might be just the kickstart that will get that subproject off the ground, because it would sidestep all the Commons navel-gazing that has effectively blocked its creation so far. I know Hen is on this list. Hen, any thoughts here before I propose this on [EMAIL PROTECTED] -- Martin Cooper Don > > Ted Husted wrote: > > On 4/22/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > >> I have these same concerns. That is why my preference would be for > Tiles to > >> stay here until Jakarta Web Components (nee Jakarta Silk) gets off the > >> ground, and then move there, where it can share a general purpose > >> web-focussed community and mindshare. > >> > > > > That sounds fine, though I wonder if adding Tiles to Jakarta Web > > Components might help that project get off the ground, the way our > > moving BeanUtils and friends to Commons gave that effort a boost. > > Every mall needs an anchor. :) > > > > -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] > >
Re: Standalone Tiles as TLP
I would think it would be Tiles' responsibility to support deployment with Struts. In that view, Tiles would be its own project, yet part of it would depend on struts-action.jar to provide the Struts hooks. In the same way, they would provide Struts Action 2 hooks, if necessary. Don Wendy Smoak wrote: On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: Agreed. Would it be possible to do this by JavaOne? Moving Tiles isn't a huge deal, but it would make the new directions of Struts easier to explain to users. What happens to Struts Tiles, then? I'm not sure I understand why we're holding Struts Tiles out of the Struts Action distribution. Won't there always be a struts-tiles.jar of some kind, whether it's the current one with all the code, or a much lighter version that works with Standalone Tiles? -- 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]
Re: Standalone Tiles as TLP
On 4/23/06, Don Brown <[EMAIL PROTECTED]> wrote: > Agreed. Would it be possible to do this by JavaOne? Moving Tiles isn't > a huge deal, but it would make the new directions of Struts easier to > explain to users. What happens to Struts Tiles, then? I'm not sure I understand why we're holding Struts Tiles out of the Struts Action distribution. Won't there always be a struts-tiles.jar of some kind, whether it's the current one with all the code, or a much lighter version that works with Standalone Tiles? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
Agreed. Would it be possible to do this by JavaOne? Moving Tiles isn't a huge deal, but it would make the new directions of Struts easier to explain to users. Don Ted Husted wrote: On 4/22/06, Martin Cooper <[EMAIL PROTECTED]> wrote: I have these same concerns. That is why my preference would be for Tiles to stay here until Jakarta Web Components (nee Jakarta Silk) gets off the ground, and then move there, where it can share a general purpose web-focussed community and mindshare. That sounds fine, though I wonder if adding Tiles to Jakarta Web Components might help that project get off the ground, the way our moving BeanUtils and friends to Commons gave that effort a boost. Every mall needs an anchor. :) -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]
Re: Standalone Tiles as TLP
On 4/22/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > I have these same concerns. That is why my preference would be for Tiles to > stay here until Jakarta Web Components (nee Jakarta Silk) gets off the > ground, and then move there, where it can share a general purpose > web-focussed community and mindshare. That sounds fine, though I wonder if adding Tiles to Jakarta Web Components might help that project get off the ground, the way our moving BeanUtils and friends to Commons gave that effort a boost. Every mall needs an anchor. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
On 4/22/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 4/21/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > > > > On Apr 21, 2006, at 7:56 AM, Ted Husted wrote: > > > > > IMHO, once Standalone Tiles is ready for a release, we should migrate > > > the component to a top-level ASF project. When we started this > > > process, the original intent was to decompose Tiles here, test it in > > > Action and Shale, and then move it out when it was ready to stand on > > > its own. > > > > > > > I agree with your points about Tiles not being an application > > framework, etc. My only concern about making it a TLP is developer > > support. Granted, this could be an issue no matter where Tiles > > lives. But there are not throngs of people jumping in to help with > > the refactoring efforts. I wonder if there are enough people > > interested in developing Tiles to support its own TLP. > > > I have these same concerns. That is why my preference would be for Tiles to > stay here until Jakarta Web Components (nee Jakarta Silk) gets off the > ground, and then move there, where it can share a general purpose > web-focussed community and mindshare. +1 I think that would be a great community for Tiles to join. > -- > Martin Cooper > > > Greg > > > > > > - > > 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]
Re: Standalone Tiles as TLP
On 4/21/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > On Apr 21, 2006, at 12:03 PM, Don Brown wrote: > > > The lack of developer support is worrisome, though, regardless what > > we do with it. > > I think there's a lot of impression that Tiles is "done." From what > I can tell it pretty much fulfills 80% of the use cases and there are > workarounds for others. Most of the innovations I can think of > overlap with the portlet or JSF spaces enough that I'm not sure if > they are worth doing. When we started refactoring it I questioned > whether it was really a worthwhile effort or if it would have a > limited lifespan. I still question that at every step along the > way :-) Should we just make the bare minimum changes to get Tiles > out of the sandbox or is it worth it to do major surgery? I agree that it's really mostly "done". (I'm not sure what other people meant by a +1 to an either / or question, but I suspect they mean they agree it's "done" too.;) Whether it's worth major surgery is really a question of whether there are people who have the itch to perform that surgery. If there are, that's great. If not, I think it's just fine to do only what's necessary to get a standlone version out into the wild. -- Martin Cooper There are a few other technologies I want to spend time looking at > once we get a release of Tiles. I'd like to see how it compares to > Facelets, Clay, and Sitemesh, as well as how much relevance Tiles has > in a portlet environment. Those things may help to determine the > future of Tiles. > > Those are just my thoughts. > Greg > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Standalone Tiles as TLP
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. > > > 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. If Tiles has become a one-developer show, then > we have deeper problems that we need to fix now. > > > 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 No, not at all. Certainly Shale builds on top of JSF, but Action building on top of JSP? Hardly. Sure, we have some tag libraries, but the real focus of Action has nothing to do with 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'm honestly not sure why anyone would want to merge Action and Shale. They provide different models for building web applications. Mixing those would be a little odd, IMHO. On the other hand, I can certainly see sharing some code across the two. 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. Again, this analogy doesn't work. If you pulled BeanUtils out of Struts, a lot of what's left would just fall flat on its face. That's not the case if you pull out Tiles, especially if you're not using JSP in the first place. When we extracted all the other components, we gave them > lives of their own in the Commons. We should pay Tiles the same > courtesy. OK, this part I agree with. :-) But I don't think a TLP is the right place. -- Martin Cooper -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Standalone Tiles as TLP
On 4/21/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > On Apr 21, 2006, at 7:56 AM, Ted Husted wrote: > > > IMHO, once Standalone Tiles is ready for a release, we should migrate > > the component to a top-level ASF project. When we started this > > process, the original intent was to decompose Tiles here, test it in > > Action and Shale, and then move it out when it was ready to stand on > > its own. > > > > I agree with your points about Tiles not being an application > framework, etc. My only concern about making it a TLP is developer > support. Granted, this could be an issue no matter where Tiles > lives. But there are not throngs of people jumping in to help with > the refactoring efforts. I wonder if there are enough people > interested in developing Tiles to support its own TLP. I have these same concerns. That is why my preference would be for Tiles to stay here until Jakarta Web Components (nee Jakarta Silk) gets off the ground, and then move there, where it can share a general purpose web-focussed community and mindshare. -- Martin Cooper Greg > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Standalone Tiles as TLP
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]
Re: Standalone Tiles as TLP
> Should we just make the bare minimum changes to get Tiles > out of the sandbox or is it worth it to do major surgery? +1 Tiles is pretty mature and I don't sense a lot of interest in perfecting it. It would be nice to have it stand on its own (dependency wise) but I'm not volunteering. Tiles needs a home and it already lives in Struts. Lets leave it alone and move on to more interesting things. > Greg Sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
>From: Greg Reddin <[EMAIL PROTECTED]> > > > On Apr 21, 2006, at 12:03 PM, Don Brown wrote: > > > The lack of developer support is worrisome, though, regardless what > > we do with it. > > I think there's a lot of impression that Tiles is "done." From what > I can tell it pretty much fulfills 80% of the use cases and there are > workarounds for others. Most of the innovations I can think of > overlap with the portlet or JSF spaces enough that I'm not sure if > they are worth doing. When we started refactoring it I questioned > whether it was really a worthwhile effort or if it would have a > limited lifespan. I still question that at every step along the > way :-) Should we just make the bare minimum changes to get Tiles > out of the sandbox or is it worth it to do major surgery? > +1 > There are a few other technologies I want to spend time looking at > once we get a release of Tiles. I'd like to see how it compares to > Facelets, Clay, and Sitemesh, as well as how much relevance Tiles has > in a portlet environment. Those things may help to determine the > future of Tiles. > In the JSF front, Tiles provides JSP composition. Facelets and Clay provide page composition from templates but not JSP template fragments. Clay can be used in a JSP page but cannot include a JSP fragment in it's composition. > Those are just my thoughts. > Greg Gary > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: Standalone Tiles as TLP
On Apr 21, 2006, at 12:03 PM, Don Brown wrote: The lack of developer support is worrisome, though, regardless what we do with it. I think there's a lot of impression that Tiles is "done." From what I can tell it pretty much fulfills 80% of the use cases and there are workarounds for others. Most of the innovations I can think of overlap with the portlet or JSF spaces enough that I'm not sure if they are worth doing. When we started refactoring it I questioned whether it was really a worthwhile effort or if it would have a limited lifespan. I still question that at every step along the way :-) Should we just make the bare minimum changes to get Tiles out of the sandbox or is it worth it to do major surgery? There are a few other technologies I want to spend time looking at once we get a release of Tiles. I'd like to see how it compares to Facelets, Clay, and Sitemesh, as well as how much relevance Tiles has in a portlet environment. Those things may help to determine the future of Tiles. Those are just my thoughts. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
I'm with Ted on this - Tiles really should be standalone and out on its own, lest Struts just be an umbrella project. It is the odd man out next to Shale and Action, and would benefit from a wider audience. Either Tiles as a TLP, Jakarta project or Jakarta Commons would fit to me. The lack of developer support is worrisome, though, regardless what we do with it. Don Ted Husted 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. 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. If Tiles has become a one-developer show, then we have deeper problems that we need to fix now. 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. 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. -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]
Re: Standalone Tiles as TLP
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. > 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. If Tiles has become a one-developer show, then we have deeper problems that we need to fix now. > 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. 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. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
On 4/21/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > I agree with your points about Tiles not being an application > framework, etc. My only concern about making it a TLP is developer > support. Granted, this could be an issue no matter where Tiles > lives. But there are not throngs of people jumping in to help with > the refactoring efforts. I wonder if there are enough people > interested in developing Tiles to support its own TLP. We will need the same number of binding votes to release Tiles either way. If there isn't enough support for Tiles as a TLP, then there isn't enough support for Tiles as a subproject either. As a TLP, Tiles would have a chance to attract developers from outside the Apache Struts community. If it stays buried here, then people will brush it off as a "Struts" thing, and Tiles won't have a chance to attract its own community of developers. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
On 4/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: > Lately, we've gotten into the habit of talking about Standalone Tiles > as if it were already an Apache Struts subproject. As far as I > remember, there has never been a vote to that effect, and the only > proposal on the wiki positions Tiles as a top-level project, once it > is ready to stand on its own. > > * http://wiki.apache.org/struts/TilesTopLevel > > IMHO, once Standalone Tiles is ready for a release, we should migrate > the component to a top-level ASF project. When we started this > process, the original intent was to decompose Tiles here, test it in > Action and Shale, and then move it out when it was ready to stand on > its own. > > If anything will make Apache Struts an "umbrella", it would be keeping > Tiles here, rather than proposing it as a top-level project. > Standalone Tiles is *not* an application framework. Tiles is a > *component" that can be used by any web application, just like > Validator and BeanUtils and everything else we extracted into > "standalone" versions. > > Of course, another alternative would be to propose Tiles as Commons > component or Jakarta subproject. Albeit, I feel that Tiles falls > somewhere between a component and a framework, and that Tiles is rich > enough to warrant its own top-level project. > > Thoughts? Do we need to be discussing this now? I kinda feel like this should wait until Tiles is ready to stand alone. 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. 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. > -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]
Re: Standalone Tiles as TLP
On Apr 21, 2006, at 7:56 AM, Ted Husted wrote: IMHO, once Standalone Tiles is ready for a release, we should migrate the component to a top-level ASF project. When we started this process, the original intent was to decompose Tiles here, test it in Action and Shale, and then move it out when it was ready to stand on its own. I agree with your points about Tiles not being an application framework, etc. My only concern about making it a TLP is developer support. Granted, this could be an issue no matter where Tiles lives. But there are not throngs of people jumping in to help with the refactoring efforts. I wonder if there are enough people interested in developing Tiles to support its own TLP. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standalone Tiles as TLP
think so too,that there is no public "tiles-core.jar" on any m2 repo, IMO -Matthias > -Original Message- > From: Sean Schofield [mailto:[EMAIL PROTECTED] > Sent: Friday, April 21, 2006 4:20 PM > To: Struts Developers List > Subject: Re: Standalone Tiles as TLP > > Right but there hasn't been a release of stand alone tiles > yet has there? If there are maven jars for standalone then > we'll switch now. > > Sean > > On 4/21/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > > On Apr 21, 2006, at 8:41 AM, Sean Schofield wrote: > > > > > As for top level project, I agree that Tiles probably > belongs here > > > but I'm not opposed. For me the main thing is that Tiles > should be > > > decoupled from the Action framework. MyFaces Tomahawk currently > > > requires the full struts jar in order to provide Tiles support. > > > > That's only because Tomahawk is using Struts Tiles instead of > > Standalone Tiles, right? > > > > Greg > > > > > > > - > > 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]
RE: Standalone Tiles as TLP
> That's only because Tomahawk is using Struts Tiles instead of > Standalone Tiles, right? right, Shale's TilesViewHandler.java requires the following clazzes of tile-core.jar import org.apache.tiles.ComponentContext; import org.apache.tiles.ComponentDefinition; import org.apache.tiles.DefinitionsFactoryException; import org.apache.tiles.NoSuchDefinitionException; import org.apache.tiles.TilesUtil; -Matthias > Greg > > > - > 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]
Re: Standalone Tiles as TLP
Right but there hasn't been a release of stand alone tiles yet has there? If there are maven jars for standalone then we'll switch now. Sean On 4/21/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > On Apr 21, 2006, at 8:41 AM, Sean Schofield wrote: > > > As for top level project, I agree that Tiles probably belongs here but > > I'm not opposed. For me the main thing is that Tiles should be > > decoupled from the Action framework. MyFaces Tomahawk currently > > requires the full struts jar in order to provide Tiles support. > > That's only because Tomahawk is using Struts Tiles instead of > Standalone Tiles, right? > > Greg > > > - > 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]
Re: Standalone Tiles as TLP
On Apr 21, 2006, at 8:41 AM, Sean Schofield wrote: As for top level project, I agree that Tiles probably belongs here but I'm not opposed. For me the main thing is that Tiles should be decoupled from the Action framework. MyFaces Tomahawk currently requires the full struts jar in order to provide Tiles support. That's only because Tomahawk is using Struts Tiles instead of Standalone Tiles, right? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles as TLP
So you are suggesting Tiles be decoupled from Struts Action and Shale so that it can be compiled independent of these modules? Definite +1 and this was my impression all along as well. As for top level project, I agree that Tiles probably belongs here but I'm not opposed. For me the main thing is that Tiles should be decoupled from the Action framework. MyFaces Tomahawk currently requires the full struts jar in order to provide Tiles support. Sean On 4/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: > Lately, we've gotten into the habit of talking about Standalone Tiles > as if it were already an Apache Struts subproject. As far as I > remember, there has never been a vote to that effect, and the only > proposal on the wiki positions Tiles as a top-level project, once it > is ready to stand on its own. > > * http://wiki.apache.org/struts/TilesTopLevel > > IMHO, once Standalone Tiles is ready for a release, we should migrate > the component to a top-level ASF project. When we started this > process, the original intent was to decompose Tiles here, test it in > Action and Shale, and then move it out when it was ready to stand on > its own. > > If anything will make Apache Struts an "umbrella", it would be keeping > Tiles here, rather than proposing it as a top-level project. > Standalone Tiles is *not* an application framework. Tiles is a > *component" that can be used by any web application, just like > Validator and BeanUtils and everything else we extracted into > "standalone" versions. > > Of course, another alternative would be to propose Tiles as Commons > component or Jakarta subproject. Albeit, I feel that Tiles falls > somewhere between a component and a framework, and that Tiles is rich > enough to warrant its own top-level project. > > Thoughts? > > -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]
Standalone Tiles as TLP
Lately, we've gotten into the habit of talking about Standalone Tiles as if it were already an Apache Struts subproject. As far as I remember, there has never been a vote to that effect, and the only proposal on the wiki positions Tiles as a top-level project, once it is ready to stand on its own. * http://wiki.apache.org/struts/TilesTopLevel IMHO, once Standalone Tiles is ready for a release, we should migrate the component to a top-level ASF project. When we started this process, the original intent was to decompose Tiles here, test it in Action and Shale, and then move it out when it was ready to stand on its own. If anything will make Apache Struts an "umbrella", it would be keeping Tiles here, rather than proposing it as a top-level project. Standalone Tiles is *not* an application framework. Tiles is a *component" that can be used by any web application, just like Validator and BeanUtils and everything else we extracted into "standalone" versions. Of course, another alternative would be to propose Tiles as Commons component or Jakarta subproject. Albeit, I feel that Tiles falls somewhere between a component and a framework, and that Tiles is rich enough to warrant its own top-level project. Thoughts? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
