On Wed, Mar 13, 2013 at 12:16 PM, Christian Schneider < ch...@die-schneider.net> wrote:
> Another problem is that at least eclipse + m2e does not cope very well > with provided scope and embedded bundles. > > So for example I still can not have the karaf console project open in > eclipse. As soon as I open it all projects depending on the console > are flagged as broken as they do not see the embedded dependencies anymore. > > So while this may be a bug in m2e it shows the many problems developers > face when embedding stuff. > This is why I think it is the easier path to not embed and instead live > with some more bundles and broken isolation in some cases. > > Generally speaking, I don't really want to favor ease of development wrt to features. I'm not using eclipse, so that's maybe why I haven't hit those problems. Maybe someone has a way around for eclipse. > I think the more general problem here that also shows in ops4j is that > projects introduce too many internal and external libs. Sometimes a lib > from commons is used just to have a 10 line util function. So I think what > we wall have to do is to try to keep dependencies as low as possible which > is very hard ... I think the point of utility classes is to avoid rewriting stuff and copying things around. That's really worthwhile and we should keep them. We also use some from felix utils and karaf utils, which at the time, I specifically packaged as jars to avoid having them deployed as bundles. I think my view is slightly different because I may be using karaf in a much more dynamic way than the typical user, installing, updating, uninstalling features and bundles on the fly using fabric. In such environments, having good modularity is much more important than any pain at dev time. I've seen the problems you mention during dev time too, but really, I'm willing to suffer that pain. > > > Christian > > > > On 13.03.2013 11:46, Guillaume Nodet wrote: > >> On Wed, Mar 13, 2013 at 11:32 AM, Christian Schneider < >> ch...@die-schneider.net> wrote: >> >> I have experienced some problems when libs were embedded in bundles: >>> >>> When the bundle is a separate project from the original jar that does not >>> embed the lib then the maven dependencies can not be used to create the >>> feature. >>> So in the feature you have to use the bundle but exclude its dependencies >>> so the feature does not additionally contain the original jar and the lib >>> jar. >>> >>> >>> Bundles embedding dependencies should mark them as provided in their >> pom : >> it should prevent those dependencies to be used as transitive. For jars >> repackaged as bundles, the use of the shade maven plugin allows rewriting >> a >> pom without those dependencies. >> >> >> When the bundle that embeds the lib is the original project. Then the jar >>> is not very suitable for usage outside osgi. You will easily get the same >>> package from several jars. >>> >>> That's the eternal problem with flat class loaders, but we're talking >> about >> bundles here, so their use outside OSGi is really anecdotic. And that's >> the nature of OSGi anyway, you have to live with the fact that you may >> have >> multiple versions of a single jar in your dependency tree, something that >> maven does not really support anyway, but it's no specific to OSGi. >> Inside >> a given project, it can always be controlled using the managed >> dependencies >> section. >> >> >> Sometimes I also got strange classloading problems when a lib is embedded >>> by several bundles. >>> >>> If the library surfaces to outside the bundle, i.e. by passing objects >> to >> other bundles, that means it should be flagged in the use clauses of the >> exported API and imported as a bundle. If the implementation is kept >> internal for the implementation, there's no way it can happen (unless >> there's a bug somewhere). >> >> >> So while in an ideal world OSGi dependency resolution based on pure >>> packages should work with bundles embedding libs I thnk it is not such a >>> good idea. >>> >>> Christian >>> >>> >>> On 13.03.2013 11:21, 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: >>>> >>>> >>>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> >>> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
