cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [osgi] Initial code
Date Thu, 09 Jun 2005 09:54:56 GMT
Leszek Gawron wrote:

> Daniel Fagerstrom wrote:
>
>> I have committed some initial osgi code in whiteboard 
>> (whiteboard/osgi) so that we can start experiment with a microkernel 
>> based Cocoon, http://marc.theaimsgroup.com/?t=111659646800003&r=1&w=2.
>
> <snip/>
> I find the subject very interesting so I'll look into that ASAP.

Great!

>> My plan is to continue along whats outlined in 
>> http://marc.theaimsgroup.com/?t=111659646800003&r=1&w=2. It would be 
>> more fun to work together on this, I would apprciate any involvement.
>
> How could I help?

First by following the instructions I gave and verify that it works that 
far.

Then it depends on what aspects you feel like working on. The main plan 
this far is in the link above. Things that needs to be done besides what 
I described there are:

* Integrate the build system with Cocoons build system and preferably 
the block build system so that it rebuilds the cocoon.jar etc if needed.

* The current build system from Knoplerfish configures everything in the 
build file, it would be better to base configuration from block.xml, 
that would require some aditions to block.xml (or some other 
configuration file), for handling package level export and import and 
the internal bundle classpath (used when the bundle contains library jars).

* Better development environment: remove current wrinkle and make it as 
easy to use as possible, test the desktop from Knoplerfish, find out how 
to develop bundles in Eclipse, etc.

Other things that would be interesting to start looking at:

* Component management under OSGi. Whithin blocks I guess we will 
continue to use our current set of mechanisms, but between the blocks it 
is better to publish component containers as OSGi services. Then e.g. 
the BlocksManager could connect to the component container services and 
make them available through the local ECM++ through the usual service 
mechanism. Here one could see if there already are some Spring, Hivemind 
etc bundles (or plugins) that we could use or get isnpiration from.

* Logging management, OSGi have some kind of standardised logging 
service, what does it do? would it be interesting to connect our logging 
system to the logging service?

* URL management, OSGi have a URL service that makes user defined 
schemes available though java.net.URL IIUC, could we connect our 
Excalibur Sources to this mechanism?

* Should we package some of the libreraries we use in core and at other 
places and import them through OSGi to the Cocoon core bundle etc. What 
about having API and interface bundles?

And numerous other things that we will find out when we start to work 
with it.

So it is up to you, what do you want to work on?

/Daniel


Mime
View raw message