Hi, I understand Enrico and I think his big picture is valid. From the discussion I see that we may have to work on our commons layer and simplify that one.
I see that Reto is pointing a lot on the use of those legacy technologies. Work has started to remove them but this was not adopted completely, yet. Defining a slim commons-2.0 sounds like a reasonable approach to me. Having a sound definition of how things should work in commons, we could plan for a sprint to adapt to the new commons in one step. This would clean our code base and bring everything back on the same level. Best, - Fabian 2013/5/27 Reto Bachmann-Gmür <[email protected]>: >> >> I can also not see any of such issues. If someone wants to make major >> changes to commons ... open a branch; implement the change; port some >> components to give examples on how the new structure should look like >> and agree on it within the community; upon acceptance give the >> developers time to adapt their components to the new structure; merge >> the new things back into trunk. >> > > I'm not sure why you think creating branches would help. > > Example of pervasive legacy technologies usage include: > - Non RESTfull Http Endpoints: The technologies to create semantic RESTfull > services (i.e. services that can be consumed by client having nothing but a > singe entry URI and understand mime types and ontologies) is there. It is > exemplified and supported by archetypes, yet most of our code still has > tightly coupled HTML interfaces. > - Using Jersey specific classes: From my understanding of the discussions > on the list there is a consensus that we should write our code so that it's > portable across Jax-Rs implementations. The code to support things like > multipart form without jersey dependencies has been in trunk for a while. > - ServletContext to access services / communication between components. We > could have a branch where this ugly hack is no longer available, but doubt > this would be incentive enough for people to remove this stuff. > - Use of some scattered around ontological terms from non-standard > ontologies hardcoded in some java. > - Whiteboard pattern for JAX-RS resources: It's there, still most code is > using the WebFragements > > Stanbol is currently missing it's goal of providing RESTfull services and > the size of commons also affects the re-usability as OSGi components. An > approach would be to define a slimmed down "commons 2.0" designed to > enforce a design that leads to the creation of Semantic RESTfull services > and that comprise a smaller set of library so that Stanbol can more easily > be run within any OSGi application and with any JAX-RS implementation. If > we decide to go this way we could set a timeline to phase out commons 1.0. > This would be more work than just cutting out some components but this > takes into account that the size of a code base isn't the main criterion > for it's maintainability. > > Cheers, > Reto -- Fabian http://twitter.com/fctwitt
