Felix Meschberger wrote > Hi all, > > We currently have a multi-faceted issue: We have the Sling API bundle > containing a number of utility classes (HtmlResponse, ResourceUtil). In > addition there are two utility classes in the Engine bundle > (RequestUtil, ResourceUtil) which are of general interest. > > The problem with the locations of these classes are (1) mixing > implementations into an API bundle is problematic, (2) extending > implementations means increasing the API version, (3) using the Engine > bundle utilities creates a dependency on the Engine bundle. > > I think we should create a new Utilities bundle which will host these > utility classes. > > The classes are simply copied and then further developed in the new > utilities bundle while the old classes are simply deprecated and removed > in future versions. This will keep the classes distinct and not create a > dependency to the new util bundle in the API bundle. > > WDYT ?
I don't have a definitiv answer. Now I think that having a dependency on the engine bundle is bad and maybe we could move all the public stuff from the engine bundle to somewhere else - either the api bundle or a possible new utility bundle. I'm not worried about too many bundles, but I'm a little bit worried about too many dependencies or modules a developer has to know when developing a sling application. having the utility code in the api bundle has the advantage that everything a developer has to know and needs is in a single place. And in addition things like the ResourceUtil class (in the api) are very useful and you can make good use of it all over the place. But on the other hand we have a bug to add most of these methods to the resource interface :) So I'm definitly +1 on moving things out of the engine bundle. Carsten -- Carsten Ziegeler cziege...@apache.org
