Daniel Fagerstrom wrote: > > At least for OSGi R3, each block (bundle) must export a unique set of > packages. It would be nice if we could move all classes and interfaces > so this is the case and deprecate the block classes and interface with > non unique packages before we release 2.2.0 final. It is not particulary > complicated but requires some work. > > It is necessary (if it hasn't changed in R4), that we move to block > unique package names before we start to release OSGi functionality. So > the sooner we can deprecate the non unique package use, the better. But > it is not a blocker for 2.2. > I think someone mentioned that R4 does not require the unique package names anymore. hmm, but I'm not sure.
> It is not necessary to split into api and implementation for introducing > OSGi, but it will certainly be easier to use, and scale much better if > we do it. Especially when there are several blocks implementing the same > api, it will simplify things if we have separate api blocks. Then the > api blocks that a block depends on can be downloaded during compilation > of the block, and the user can choose between several implementaions of > the used apis while deployoing the block. > Yepp. > Spliting the code into api and implemetation require however > considerable work and thought as not everything is designed with such a > split in mind. So I think that is something that we need to work on > incrementally. > Agreed. > --- o0o --- > > Considering what we need to _change_ to get real blocks: The only thing > I know about is some package renaming as discussed above. It will be > more about _adding_ things. We will need manifest files with OSGi info > in and we will need block.xml that describe dependencies on other blocks > and bundles (this need to be integrated with the m2 dependecy > information). The block.xml will also contain references to the blocks > (sample) sitemap and component configuration(s) as we discussed last > weak. This is all things that we can work on in an evolutionary way. > > From my current knowledge the largest remaining question is about how > to configure components that a block exposes. Part of it is clear, the > block.xml can refer to the .xconf(s) that is part of the block today and > export the components within the configuration so that it is available > to other blocks (through OSGi services as discussed earlier). This far > everything is as before, but done using OSGi instead of using compile > time mechanism. > > The question is how a user should be able to adapt the configuration of > the components of the block while using it. Today one can modify the > component configuration snippets by hand, but that is not as easy while > using blocks as the configuration will be embeded in a precompiled block > that is packaged as a bundle and asumed to be used as is. One possible > solution is to decide before hand what should be deploy time > configurable and use block attributes for this (BTW block attributes and > the setting stuff that Carsten and Ralph are discussing seem to have a > lot in common, we should see if the block attributes could be build > avbove or integrated with the settings stuff). Another solution is to > export the implementation of the components and configure them in the > block that uses them instead (don't like this though, as it don't give > any isolation). A third solution could maybe be to declare the > configuration as a "fragment" that can be overided. Fragments is an > Eclipse concept that have been made part of OSGi R4, I don't know enough > about it to say if it is usefull in this context. Other ideas? > I think one of the main problems is that you never know what configuration a component uses/requires. So I think we need a formal description for each configurable component, like a schema or something. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
