sorry dude, I'm also with +1 with Guillaume and JB I don't see a real benefit to open another construction-site here. Don't we have enough of those already?
ever thought about YAGNI? regards, Achim 2012/3/23 Jean-Baptiste Onofré <[email protected]>: > +1 with Guillaume. > > I'm not against, but I don't see a huge value. > > The key point is to have maximum granularity (even if we have bundle which > contains only one interface) because it provides a more flexible way to > create associated features. > > Regards > JB > > > On 03/23/2012 01:20 PM, Guillaume Nodet wrote: >> >> I would tend to favor coarse grained bundles, but for a given service, >> i.e. >> have a bundle which contain all the feature api + impl + management + >> commands, same for others. >> >> Plus, having fine grained bundles gives our users the benefit of being >> able >> to remove some part without any difficulties, for example, if one does not >> want JMX management, not installing all the management bundles is enough. >> >> We could have an additional packaging for ease of use which would bring >> into a single bundle a bunch of those, but I'm not sure who would use it. >> >> So I'm not sure I really see the benefits in what you propose beyond >> reducing the number of bundles, which I don't think is really a problem in >> itself. >> >> >> On Thu, Mar 22, 2012 at 13:58, Christian Schneider >> <[email protected]>wrote: >> >>> Hi all, >>> >>> some day ago I created the issue below: >>> >>> https://issues.apache.org/**jira/browse/KARAF-1273<https://issues.apache.org/jira/browse/KARAF-1273> >>> >>> The idea is that we might be able to reduce the number of bundles >>> considerably by joining several modules we have right now into one >>> module. >>> The commonality of these modules is that they are basically always loaded >>> in karaf and do not draw in additional dependencies. >>> >>> To consolidate these is most interesting for the api (.core) and the >>> service impls (.core.internal) as both are very small for each module. I >>> am less sure for the commands as there are more classes and also more >>> config in the blueprint file. >>> >>> Some other things to discuss is the package structure and if we should >>> separate an API package from the service impls. >>> >>> So about the package structure I see two possible designs: >>> >>> 1) >>> org.apache.karaf.framework.**bundle.core >>> org.apache.karaf.framework.**bundle.core.impl >>> org.apache.karaf.framework.**service.core >>> org.apache.karaf.framework.**service.core.impl >>> ... >>> >>> 2) >>> >>> org.apache.karaf.bundle.core >>> org.apache.karaf.bundle.core.**impl >>> org.apache.karaf.service.core >>> org.apache.karaf.service.core.**impl >>> ... >>> >>> 1) Has the advantage that you see from the parent package what belongs to >>> framework. The disadvantage is that we have to change the packages and >>> are >>> less felxible to separate them into bundles later if we want to. >>> >>> 2) Has the advantage that we do not have to change the packages and that >>> we are flexible how to package them. The disadvantage is that it is less >>> clear what package ends up in what jar. >>> >>> >>> The other issue is the API module. I think it would make sense to have an >>> API module that contains: >>> >>> org.apache.karaf.bundle.core >>> org.apache.karaf.service.core >>> org.apache.karaf.bundle.**management >>> org.apache.karaf.service.**management >>> >>> That would allow users of the mbeans or services to just depend on the >>> API >>> package and not get into contact with the impl. Of course in our current >>> structure the impls are hidden inside OSGi anyway but not at build time / >>> in the IDE. We could further separate API and management API but I think >>> this is not really necessary. >>> >>> >>> So if we choose Variant 2 and separate out the api we would have: >>> >>> framework/api >>> org.apache.karaf.bundle.core >>> org.apache.karaf.service.core >>> org.apache.karaf.bundle.**management >>> org.apache.karaf.service.**management >>> ... >>> >>> framework/core >>> org.apache.karaf.bundle.core.**internal >>> org.apache.karaf.service.core.**internal >>> ... >>> >>> framework/management >>> org.apache.karaf.bundle.**management.internal >>> org.apache.karaf.service.**management.internal >>> ... >>> >>> framework/command >>> org.apache.karaf.bundle.**command >>> org.apache.karaf.service.**command >>> ... >>> >>> >>> Christian >>> >>> >>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> Talend Application Integration Division http://www.talend.com >>> >>> >> >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/>
