My thinking also, keep things simple. The patch includes all the tests
for completeness, I guess as it was meant to be.
On 13/10/2022 08:10, Lukasz Lenart wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
