Andy Comments inline:
On 05/01/2015 18:01, "Andy Seaborne" <[email protected]> wrote: >Rob and I seem to be competing for the most commit email in a batch ... >he's ahead with 52 over my 51 :-) Most of that was from merging your recent commits to master so really you are winning ;) > >The batch I've just put in creates a sub-module structure for structure >for Fuseki2. > >I'm not entire happy with the module design but I feel it's (much) >closer to a proper answer and need refining. In order to get our >processes stable, I thought it was better to make the major change now. >Please yell if anything get broken as a result. > >And I would appreciate suggestions to improve it. > >Modules: > >jena-fuseki2 top and parent >jena-fuseki2-core The servlets and webapp >jena-fuseki2-war Package as a WAR file >jena-fuseki2-server Build an uber jar >jena-fuseki2-dist Build a binary distribution > >Fuseki can be run as a standalone server (like and compatible with >Fuseki1), as a webapp WAR in Tomcat et al, and, eventually, an embedded >mode. > >What I don't like about the current partition is: > >1/ Testing: it gets done in jena-fuseki2-core, but that needs a >webserver so the Jetty specific part is in jena-fuseki2-core. It'd like >it to be pure servlets. > >2/ Development: being about to run it without classpath management is >really helpful. This is current run jena-fuseki2-core with it's jetty >server. > >Maybe a jena-fuseki2-embedded could be done with the Jetty setup there >and put all testing that needs a running server to that as well. Seems >a little artificial. Yes I would suggest going this route, make jena-fuseki2-core be purely the servlet implementations and have the war module contain the web app. You can then add the additional embedded module to do the testing that needs a web server. Anything that doesn't need a web server (such as utility code e.g. conneg) should be tested in jena-fuseki2-core > >3/ The webapp for the admin and data management is in jena-fuseki2-core >- it needs to get into the war file and the distribution for the onejar >server file. This is currently by file name reference across modules >and that feels like the wrong thing to do. > >One possibility is always making a WAR file, making the standalone >server be a runner for the WAR file. The downside is that what was a >single jar that can run directly and also used as a "jar of all Jena" >(caveat - current setup needs a setup fix if run directly - the wrapper >scripts set environment variables). > >As a war file, there are more bits and pieces yet the single file means >that the bits and pieces don't get separated. The server is meant to be >the really, really way to run it. > >Does anyone know of a process to convert between a WAR file and a >uberjar (either way could be useful) short of grunging the file layout >explicitly. Well if the war is a dependency of the uberjar project and you include dependencies that would work (I think). You of course still need to figure out how to structure the launcher scripts so they can run this. Perhaps better would be to have the server module depend on the embedded module and then the server module is really just the launcher scripts plus the necessary build steps to generate the single JAR/distribution. Rob > > Andy
