An update on this - wro4j maven plugin is most certainly not the way to go
for any kind of a complex project.
It is highly restrictive when matching source files to be processed and
selecting destinations for the processed files.
You will only be happy with this solution if:
- your stylesheet philosophy involves either;
- having a monolithic single stylesheet
- constantly maintaining your wro.xml to add new stylesheets as you go
- and you're okay with the processed files being dumped into a single
directory.
- and you're also okay adding kludge to redirect all stylesheet import
paths when in production mode toward this single directory.
I'm not happy with this as a solution - having looked into all the
available options I come back to thinking that Tapestry should either
support this or we need to add this functionality in ourselves as users.
That or wro4j needs some serious contributions - from what I understand the
reason destination folders are so restrictive is because wro4j's code for
wildcards in paths used for recursive file matching is deemed fragile.
There was an issue request to this effect and it was resolved by
side-stepping the problem and hard-coding rather than resolving it.
So my next step is likely to rewrite and/or override a portion of wro4j to
do this the way Tapestry does in development - just replacing all less
files with css at the same location.
Or writing my own plugin to achieve this;
- traverse the directory structure
- process all less files
- store css files in their stead (i.e.: META-INF/assets/Some.less
compiled to META-INF/assets/Some.less)
Thanks,
a very frustrated Peter
On 27 October 2016 at 11:12, Peter Hvass <peter.hv...@jamesinnes.com> wrote:
> Agreed Dimitris - upon build is indeed best!
>
> There shouldn't be any inconsistencies provided I make sure both
> tapestry-webresources and wro4j are using the same less4j version.
>
> I imagine this will be a very standard pattern so I will aim to share the
> working wro4j maven plugin configuration I end up with so others can use it
> as an example.
>
> Once again - if anyone has already got this working it would be amazing if
> they could provide the rest with a shortcut by sharing their config!
>
> Thanks,
> Peter
>
> On 26 October 2016 at 13:23, Dimitris Zenios <dimitris.zen...@gmail.com>
> wrote:
>
>> I thing your best solution is what you described.
>>
>> Compile all less to css on building.
>>
>> On Tue, Oct 25, 2016 at 4:36 PM, Peter Hvass <peter.hv...@jamesinnes.com>
>> wrote:
>>
>> > Hello all,
>> >
>> > Sorry for the late response on this one!
>> >
>> > About the warmup page - thanks! I am using this now - it bypasses the
>> > issues I was facing with AWS ELB's health checks but still means a
>> *very*
>> > slow deployment time.
>> >
>> > I had posted a similar issue from an old work address some time ago -
>> look
>> > for '5.4 LESS Coffee to CSS JS During Build Instead of First Access' on
>> > this list. Howard replied saying this was outside Tapestry's scope and
>> > suggested using WRO4J's maven plugin.
>> >
>> > I'm aware that Tapestry used to include WRO4J as part of webresources
>> but
>> > then switched to less4j instead. I did some reading on the particular
>> Maven
>> > plugin for wro4j - it looks very fiddly indeed. Making sure it converts
>> all
>> > LESS files and dumps them right back where they were in the built war
>> file
>> > appears to be some kind of solution - I just haven't had the time (due
>> to
>> > work constraints) to investigate further yet. Has anyone else had any
>> luck?
>> >
>> > Regarding PageLoader - I tried this approach the other day - the sad
>> thing
>> > is ComponentSource.getPage (PageLoaderImpl uses this) did not seem to
>> > trigger the compilation/minification etc. of assets (and so does not
>> solve
>> > our problem). To test this I supplied my warmup page which includes all
>> of
>> > the heavy LESS files in need of compilation.
>> >
>> > Will do my best to investigate the wro4j maven plugin option - will
>> report
>> > back in case I figure something out - in the meantime if anyone else has
>> > any other ideas or approaches I would be incredibly grateful!
>> >
>> > Kindest regards,
>> > Peter
>> >
>> > On 5 July 2016 at 16:07, Peter Hvass <peter.hv...@jamesinnes.com>
>> wrote:
>> > >
>> > >> Hello all,
>> > >>
>> > >> The solution is kind of obvious here though I just wanted to feel
>> around
>> > >> for any alternatives.
>> > >>
>> > >> I'm deploying a small web application to a Tomcat 8 server handled by
>> > >> Amazon Web Service's Elastic Beanstalk service - load balancers etc.
>> > etc.
>> > >>
>> > >> This is quite a busy site - so we'll typically see around 100
>> concurrent
>> > >> users.
>> > >>
>> > >> When I deploy a new version of the web app, the 'first load' is very
>> > >> heavy - mostly due to LESS compilation (tapestry-webresources,
>> wro4j).
>> > When
>> > >> 100 concurrent users hit for that 'first load' the server immediately
>> > falls
>> > >> over in a 100% CPU death spiral.
>> > >>
>> > >> My workaround thus far has been to deploy the new version to a
>> secondary
>> > >> server, access it for the first load myself and then throw it to the
>> > >> hordes. This is annoying and time-consuming.
>> > >>
>> > >> Ideally it would be great if LESS compilation could occur as part of
>> > >> building the WAR file rather than live on the server. We never make
>> > changes
>> > >> to files inside the WAR file directly. Has anyone been able to
>> achieve
>> > this?
>> > >>
>> > >> Kind regards,
>> > >> Peter
>> > >>
>> > >
>> > >
>> >
>>
>
>
