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 > > >> > > > > > > > > >
