Carsten Ziegeler wrote:
Ralph Goers wrote:
How much do we know about the directory structure required by Maven? I
know that OSGi R3 requires a directory structure, R4 doesn't.
Don't understand the comment (from Upayavira) about directory structure,
R3 and R4, care to explain?
However,
one package per bundle would make implementation much easier.
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.
Unfortunately, my knowledge only extends to Maven 1. Carsten would have
to answer this as he has been working on the conversion to Maven 2. It
doesn't look like he has had to do much so far, but I'm still worried
that circular dependencies between blocks are going to show up.
Currently we don't have circular dependencies, so the current structure
will work with maven as well. Now m1 and m2 do not differ that much when
it comes to the directory structure: one java source directory per
project, several resource directories (if you need), on directory for
java tests etc. So this works pretty well for our current blocks.
If we want to split blocks into api and impl for example, we have to
create two maven projects - this of course then will also reduce
problems with circular dependencies.
I don't know if we need something else for osgi, but I think this
approach (api vs impl) should work there as well.
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.
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.
I just want to avoid any "we can't release X because we're waiting for
feature Y", that is something we've stumbled with all too often.
+1
We should get into the habit of releasing what we actually have done
rather, than not releasing because we developed something else than what
we planned.
Yes, I would like to avoid that as well. However, I don't know that we
need to be using a formally released Maven 2 to know how to do this.
I think time will tell. Switching to maven is currently at a very low
rate, not many of us are working on it (which is ok of course), the same
happens to the OSGi stuff. We shouldn't delay 2.2 neither because of
waiting for m2 nor waiting for OSGi. The current version seems to work
and build system works as well.
Exactly.
--- 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?
/Daniel
