Moving Tomcat + Jersey to a new repository?

[calummackervoy]

What MUD Jena does now

• Manages an triplestore via Apache Jena (#32 )
• Provides functionality conforming to the MUD spec via Apache Jena and is written to be extensible
• Exposes these endpoints via HTTP with JAX-RS

I think this is all fine, and then

• Tomcat Servlet (MUDApplication)

I think that this doesn't belong in the repository, but could be moved to its own one for providing a demo Java server which uses MUD-Jena

Your REST API using Jersey can be packaged as a .war file which is a standard, which would allow you to deploy it in a standard way under any servlet container like Tomcat or Grizzly or Jetty. Or a more modern approach is to package your application as a .jar file with a “main” and explicitly initialize an embedded servlet container like Jetty or Tomcat directly from your code. In this approach you buy simpler deployment but you of course lose sharing your servlet container with other web-apps.

[calummackervoy]

I've been wrestling with the question of whether the web-facing stuff is a concern which we should be moving to another repository (making this a library for using Apache Jena in a MUD-specific way, having another library to expose web server routes following the MUD spec, and another which is a demo deployment in Tomcat)

My current thoughts on that:

• The concern of this repository is to implement the MUD specification endpoints in Java, meaning expose them as HTTP endpoints
• The endpoints themselves should not need to be overridden but instead should provide sufficient abstraction that a Java server using it can hook into the relevant parts (e.g. by registering a custom ContentDescriber), and we should document that well so that it's easy
• The store abstraction (#32 ) should possibly have its own endpoints which can optionally be exposed to local services

Interesting question whether we want to expose other functions like registering a Describer in endpoints. In the case of the describer they just need to input/output RDF so for some local Go service that's fine - but also in the case of the describer we're planning on doing front-end federation (so the client should ask any distant content servers themselves!)

[calummackervoy]

I'm wondering if actually this isn't an implementation of the MUD specification, and we want to move that to a new repository, with this one being Java application tools for using RDF and MUD concepts

[calummackervoy]

We had a call about this yesterday and decided that for now we're going to keep everything in one repository

The reasons for considering splitting into a different repository are for the future concerns of someone wanting to use MUD-Jena:

• with Spring instead of Jersey
• with Jetty instead of Tomcat
• with a native Java application instead of a Java server

We decided it'd be better to "cross this bridge later" when the project repo is more mature