On Wed, Mar 13, 2013 at 4:01 PM, Jean-Baptiste Onofré <j...@nanthrax.net>wrote:
> Thanks Guillaume for this remember (or introduction for some of us I think > ;)). > > I think that on trunk we made some progress in the way that you describe. > For instance, unlike that we have in Karaf 2.x, modules on trunk are > structured like this: > - core provide OSGi services > - commands use the core services > - MBeans use the core services > - an end-user can use core services if he wants > Yes, and from a purely technical side, it's really nice. As Ioannis said, it can be troublesome for users that Karaf comes with 80 bundles ... It has the nasty drawback of not looking lightweight anymore ... > > Where I'm fully agree is to avoid to go too "deep" in granularity: we > already discussed of Karaf utils: it's a jar embedded in other bundles, > it's not a bundle exposing a service or API used by other bundles. > > I'm not fully agree with Christian. OSGi doesn't mean that we have to > expose all as OSGi, for instance, it doesn't make sense for Karaf utils (we > are not in a developer bullshit approach where we turn all in OSGi just for > "fun" or "elegance", we have to keep things simple, maintainable, and > coherent). > > My 0.02€ > > Regards > JB > > > On 03/13/2013 11:21 AM, Guillaume Nodet wrote: > >> Starting a new thread for discussing those points. >> >> The idea for OSGi is modularity, but it should be done at the right level. >> And modularity is different from code sharing. >> >> In OSGi, the main idea is to have bundles exposing API and services. >> That's the way we leverage the most of OSGi. >> Unlike projects like CXF or Camel, we develop for OSGi so we should try to >> use it in the best way. >> >> Let's consider the 3 different things we can have in OSGi : apis, >> implementations and libraries. >> We have basic rules: >> * service api packages should be exported >> * service implementation packages should be kept private >> When a service bundle ships the api in the same bundle as the >> implementation, the rule is to export and import the api package to let >> the >> framework use package substitution if needed. For libraries, the rule is >> to export the packages and not import those, as subsitution should never >> occur. >> >> One first case is service api and implementations. A service bundle can >> either provide its own API or the API be provided by a separate package. >> With the osgi compendium jar, it's recommended to not use it because it >> breaks modularity: this bundle provides lots of different service apis, so >> you can't change them one by one. That's why osgi service implementation >> usually ship their own API. For apis we control, things are slightly >> different, as we don't have those big bundles. For those cases, the best >> thing is actually to ship the API and the service implementation in >> different bundles. This allows updating the service implementation >> without >> requiring a refresh of the other bundles. >> >> Let's now discuss the bundle lifecycle pov. If a bundle providing a >> service depends for the implementation on libraries packages provided by >> external bundles, it breaks the abstraction and modularity to some degree >> by exposing internal constraints. Those constraints are better captured >> by >> service dependencies. >> Let's take an example: we have bundle A and B depending on a library >> provided by bundle C. If you want to update C to provide a fix needed for >> A, this will also impact B, which could cause a regression to B >> functionality. There are transient ways around that: i.e. deploy a new >> version of bundle C or update C and only refresh A. But those are only >> transient as in felix, the wiring isn't retained across restarts. And >> this >> can't really be controlled well with the tools we have at hand. >> On the other hand, if both bundle A and B embeds the C library needed you >> can update A and B independently, so a better modularity at the cost of >> less code sharing. >> >> So in an ideal OSGi world, service APIs would be shipped in individual >> bundles, and service implementation would have no other constraints than >> on >> other services. >> >> We're not in an ideal world though. For big projects such as Camel, CXF, >> ActiveMQ, there's not always a real API and other constraints may come in, >> mostly that they are not architected purely for OSGi. >> Anyway, for small library bundles that can easily be embedded, I think we >> should do it: there's no drawbacks I can see, and it improves modularity. >> >> >> On Wed, Mar 13, 2013 at 10:05 AM, Christian Schneider < >> ch...@die-schneider.net> wrote: >> >> I do not agree with embedding bundles except for some rare cases. They >>> make it much more difficult to work with those projects. In maven you >>> always >>> get the list of dependencies including the embedded ones unless you >>> exclude them. >>> I agree though that ops4j contains too many fine grained bundles. Instead >>> of embedding I propose to check if we could just merge some of these >>> libs. >>> >>> Christian >>> >>> >>> On 13.03.2013 07:41, Guillaume Nodet wrote: >>> >>> +1 >>>> >>>> A few comments though >>>> >>>> When I started the first time, karaf failed to install the additional >>>> features (ssh, management, etc...) >>>> I then removed my ~/.m2/settings.xml which were pointing to a nexus and >>>> restarted from clean. That worked, but the bundles took a long time to >>>> install. While it works, I think going to the internet when starting >>>> is a >>>> really bad idea. >>>> >>>> karaf@root()> instance:connect test >>>> undefined option -p >>>> Try <command> --help' for more information. >>>> >>>> On a side note, the completion usability is really lessened by the >>>> subshells. We really need to fix that somehow. Maybe by having >>>> subshells >>>> ending with ':'so that completion would behave better. >>>> >>>> Another problem with subshells: when going out of a subshell, the scope >>>> isn't modified. So it's effectively as if you were still inside the >>>> subshell and you loose the default scope behavior, which is especially >>>> troubling with the list command. I.e.: >>>> > feature >>>> > exit >>>> > list >>>> the list command gives you the feature list and not the bundle list. >>>> >>>> I think some bundles are too fine grained to be deployed as is. I'm >>>> mostly referring to org.ops4j.base/* and org.ops4j.pax.swissbox/* >>>> bundles >>>> which are pure helper libraries and should imho be embedded whenever >>>> possible. I think we already had those discussions, but ideally, >>>> library >>>> bundles should be avoided. >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Mar 12, 2013 at 4:26 AM, Jamie G. <jamie.goody...@gmail.com> >>>> wrote: >>>> >>>> Hi, >>>> >>>>> >>>>> We resolved 964 issues in this release (web page will be published >>>>> post RC promotion): >>>>> >>>>> https://svn.apache.org/repos/****asf/karaf/site/trunk/src/**main/**<https://svn.apache.org/repos/**asf/karaf/site/trunk/src/main/**> >>>>> webapp/index/community/****download/karaf-3.0.0.RC1-****release.page< >>>>> https://svn.**apache.org/repos/asf/karaf/**site/trunk/src/main/webapp/ >>>>> **index/community/download/**karaf-3.0.0.RC1-release.page<https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0.RC1-release.page> >>>>> > >>>>> >>>>> >>>>> NOTE: This is a technology preview release candidate. >>>>> >>>>> Staging repository: >>>>> https://repository.apache.org/****content/repositories/**<https://repository.apache.org/**content/repositories/**> >>>>> orgapachekaraf-019/<https://**repository.apache.org/content/** >>>>> repositories/orgapachekaraf-**019/<https://repository.apache.org/content/repositories/orgapachekaraf-019/> >>>>> > >>>>> >>>>> Release tags: >>>>> https://svn.apache.org/repos/****asf/karaf/tags/karaf-3.0.0.****RC1/<https://svn.apache.org/repos/**asf/karaf/tags/karaf-3.0.0.**RC1/> >>>>> <https://svn.apache.org/**repos/asf/karaf/tags/karaf-3.**0.0.RC1/<https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/> >>>>> > >>>>> >>>>> 3.0.x Dependencies table: >>>>> >>>>> https://svn.apache.org/repos/****asf/karaf/site/trunk/src/**main/**<https://svn.apache.org/repos/**asf/karaf/site/trunk/src/main/**> >>>>> webapp/index/documentation/****karaf-dependencies/karaf-deps-** >>>>> **3.0.x.page<https://svn.**apache.org/repos/asf/karaf/** >>>>> site/trunk/src/main/webapp/**index/documentation/karaf-** >>>>> dependencies/karaf-deps-3.0.x.**page<https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page> >>>>> > >>>>> >>>>> >>>>> Please vote to approve this release: >>>>> >>>>> [ ] +1 Approve the release >>>>> [ ] -1 Veto the release (please provide specific comments) >>>>> >>>>> This vote will be open for 72 hours. >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> >>> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
