On 21/02/14 19:02, Ian Dickinson wrote:
Hi Andy,
On Fri, Feb 21, 2014 at 5:19 PM, Andy Seaborne <[email protected]> wrote:
Just got back to looking at Fuseki2 ...
It's going to be easier from a packaging point of view to switch to the
conventional maven layout using src/main/webapp,
I've managed to package a WAR from our current setup and run it as a WAR
app.
For better testing, I'd like to drive the testing off the same layout as the
.war file would have.
The main change is moving pages/*, web.xml and all the other webapp files to
src/main/webapp.
Cool, sounds like a good change. I'm hopeful that sprint 2 on my
current customer project will be a bit less insane^h^h^htense than
sprint1, and I'll have some time in the evenings to get back to the
Fuseki UI.
Ian
Changes made and I've managed to build and run as a WAR file using
maven. Still to do is decide on the filesystem layout and where to put
it when dropped into tomcat; Jetty is easier in that respect.
I'm in two+ minds about how to structure the build.
Currently, it's one module producing a jar, a shared uber jar and a war
file (and the tests jar because jena-jdbc-remote uses that). The war
file is attached to the package phase so it is very like a
<packaging>war</packaging>.
The shade plugin needs a Fuseki jar to work from - as far as I can see,
it won't include class files directly (I'm sure I'm missing something
here as that would seem an obvious thing to do).
Having 3 modules (core, server uberjar (and assembly?), server war) is
nice from the separation point of view but seems to get messy as to
where webapp resources, which are used by standalone and war forms, as
well as for development.
If we didn't care at all about compatibility, the standalone could be
the war file + a jetty runner (that works). What it loses if the
command line usage. The command line is much smaller than it was and
everything internally is a webapp war - the command line puts the setup
intoa known static for the webapp to pick up in the ServletContextListener.
Andy
