To be honest, I would like to reduce as much as possible by taking some custom steps to generate something. I do not expect to have a lot of issues around Tiles or new feature requests, so having this as simple as possible is the way to go :)
Cheers -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ wt., 11 paź 2022 o 11:24 Greg Huber <gregh3...@gmail.com> napisał(a): > > I thought about the autotag stuff and with the validation/tests etc, > seemed a good idea to keep it, as its not that involved. > > Basically it uses template-suite.xml to generate the tag files and tld. > > I have got it all working, and passing the tests. > > Rather than the maven autotag plugin, I have a simple class > (BuildJspAutotags) that builds the tags to > > /target/generated-sources/autotag > > And then if changing the template-suite.xml, run the build and copy > manually the classes/tld back into the source. > > The org.apache.struts2.tiles.BuildJspAutotags.java probably needs a > better home. > > I have committed all this to > > https://github.com/gregh3269/struts/tree/WW-5233-tiles > > I can will do another PR so can have a look? > > On 11/10/2022 10:00, Lukasz Lenart wrote: > > I copied some auto generated classes but they depend on Autotag > > classes, so I copied them as well. If something is still missing I > > have a Tiles build locally and can copy other auto generated stuff. > > And yes, we should avoid maintaining Autotag, it complicates things. > > As far as I understand we only use / expose JSP tags, I don't know if > > someone is using Freemarker/Velocity directives - we can always add > > them later on request. > > > > > > Regards > > Łukasz > > > > niedz., 9 paź 2022 o 16:17 Greg Huber <gregh3...@gmail.com> napisał(a): > >> Looking at it in more depth, I think we need to leave as much code as > >> possible in the attic, including the autotag stuff. Keep only the parts to > >> make it work, and update the tag classes manually. Having to maintain > >> classes to generate the tag classes is pointless (might as well update them > >> directly). If we need to generate the tld we can use the struts tld > >> processor. > >> > >> This means we don't need all of the velocity code, support classes etc and > >> should reduce the plugin packages also. > >> > >> I will play around with it to see what we can loose, so we only have the > >> bare minimum. > >> > >> > >> On Sun, 9 Oct 2022 at 10:52, Greg Huber <gregh3...@gmail.com> wrote: > >> > >>> Or better, try to build the tags (whatever the maven-autotag-pluging > >>> did) on the plugin build? > >>> > >>> On 09/10/2022 10:28, Greg Huber wrote: > >>>> The reason why the taglibs were missing, they are generated by tiles > >>>> auto tag > >>>> > >>>> https://tiles.apache.org/tiles-autotag/ > >>>> > >>>> Tiles-3 introduces a f Autotag Project, a project that automatically > >>>> generates tags (or tag-like) artifact from a common template code for > >>>> a range of templating languages. Today JSP tags, Freemarker directive > >>>> models and Velocity directives are generated from a common template > >>>> models. > >>>> > >>>> Do we use Freemarker directive models and Velocity directives? > >>>> > >>>> Maybe we don't need the autotag in the plugin as we have the tag > >>>> classes now? > >>>> > >>>> On 06/10/2022 14:05, Lukasz Lenart wrote: > >>>>> I have prepared a PR to copy Tiles code base into the Tile plugin - > >>>>> just copied what is needed by the plugin. I would like to merge it > >>>>> after releasing 6.1.0 > >>>>> > >>>>> https://github.com/apache/struts/pull/608 > >>>>> > >>>>> > >>>>> Regards > >>>>> -- > >>>>> Łukasz > >>>>> + 48 606 323 122 http://www.lenart.org.pl/ > >>>>> > >>>>> wt., 9 sie 2022 o 16:43 Antonio Petrelli <antonio.petre...@gmail.com> > >>>>> napisał(a): > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
