Hi Heiko,
Le 11/04/2013 12:10, Heiko W.Rupp a écrit :
Hi,
see the exact same failures in the github-migrated sources, which have not been touched
since 1 or two weeks.
The very same worked yesterday, so I guess that the specific version
of stuff for jspc is all of a sudden no longer available in some upstream repo.
The artifacts are in the repositories, no problem with that. I saw the
failures on Jenkins for the rhq-master-GitHub build. Yes they are the
same and are only due to animal sniffer not being able to find Jasper
classes.
> In my opinion, the latter is preferable as most if not all those JSP are not used
anymore. Besides I'm not sure the precompiled JSP are used as we do nothing with the
web.xml file generated by the jspc plugin (see
http://docs.codehaus.org/display/JETTY/Maven+Jetty+Jspc+Plugin). How the generated
servlets classes could be used if they are not declared in the war descriptor?
I fear, that if someone hits a jsp page, the server will still recompile all of them,
which is an undesired hit.
If someone hits a JSP, the server will recompile only that one (and its
dependencies).
Not pre-compiling them is a good option if we finally slim down the JSPs to the absolute
minimum
I made a build locally with dist profile activated. The precompiled JSPs
get copied in the WEB-INF/classes directory, but we do not declare them
(as servlets) in the web.xml.
I may be wrong, but I believe the container will just ignore them and
recompile JSPs at runtime anyway.
I also checked what we have in a JON zip. Same thing.
We shouldn't bother precompiling JSPs which we don't point the container at.
Heiko
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
Thomas