> > 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
