You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/07/04 07:38:48 UTC
[Blockathon] agenda proposal
I had some discussions with Daniel about the upcoming Blockathon. Don't worry,
we both don't believe that a completly organized event with a strict agenda is
that what we need and want.
We both think that placing Cocoon on the top of OSGi should be our main goal.
Doing this we should focus on
- "new" Cocoon architecture (layers, initialization, running Cocoon
in different environments, refreshing classloaders, etc.)
- component management on top of OSGi (Avalon and Spring components)
- usecases for real blocks
When we say "focus on" we mean discussions triggered by mini-presentations (10 -
15 minutes) and writing code. We don't want an event where we only do the one
and forget about the other.
Carsten, Daniel and I will prepare a couple of mini-presentations:
Daniel: OSGi
Daniel: sitemap blocks
Carsten: component management
Reinhard: usecases and deployment
These presentations will be available and can be held whenever the right moment
for them will come.
In order to make this loose organization possible, I asked Upayavira whether he
wants to take the role of the moderator. He happily accepted and will keep an
eye on the process so that we don't get side-tracked and also don't get lost in
details.
Comments, thoughts, wishes?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [Blockathon] agenda proposal
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 juil. 05, à 08:16, Antonio Gallardo a écrit :
> Yes, please! A broadcast will be great! No matter if this is going to
> be from 1:00 a.m to 4:00 a.m. morning. ;-)
I only have IChat setup, so broadcasts might not be too easy. But we'll
see what we can do!
-Bertrand, still on the train to Stuttgart
(and no we don't have wifi on trains here yet ;-)
Re: [Blockathon] agenda proposal
Posted by Antonio Gallardo <ag...@agssa.net>.
Bertrand Delacretaz wrote:
> Le 4 juil. 05, à 09:03, Leszek Gawron a écrit :
>
>> ...could you record it on video please? It's impossible for me to
>> show and these recordings would be invaluable...
>
>
> Three days of video might be a bit too much, but if people document
> the designs on whiteboards (physical dead tree ones I mean) and take
> pictures of them, it would be great already.
>
> Of course, video clips of Blockathon people explaining what they're
> doing would be way cool! I'll have my webcam with me in any case.
Yes, please! A broadcast will be great! No matter if this is going to be
from 1:00 a.m to 4:00 a.m. morning. ;-)
Best Regards,
Antonio Gallardo.
>
> -Bertrand
Re: [Blockathon] agenda proposal
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 juil. 05, à 09:03, Leszek Gawron a écrit :
> ...could you record it on video please? It's impossible for me to show
> and these recordings would be invaluable...
Three days of video might be a bit too much, but if people document the
designs on whiteboards (physical dead tree ones I mean) and take
pictures of them, it would be great already.
Of course, video clips of Blockathon people explaining what they're
doing would be way cool! I'll have my webcam with me in any case.
-Bertrand
Re: [Blockathon] agenda proposal
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
>
> I had some discussions with Daniel about the upcoming Blockathon. Don't
> worry,
<snip/>
>
> Comments, thoughts, wishes?
could you record it on video please? It's impossible for me to show and
these recordings would be invaluable.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Blockathon] agenda proposal
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 juil. 05, à 08:21, Reinhard Poetz a écrit :
> ...Danniel and I are confident that OSGi will be a good solution but
> this is still unproven. We would like to see a prototyp running after
> the 3 days so that we have something to decide and discuss about...
I'm confident to, just being careful about people's perception. And
focusing on having something that runs after 3 days is great, I agree
that it should be the main goal.
> ...Just want to mention that I don't think that our users need to know
> about OSGi at all if they don't want. They have to describe their
> block in the descriptor (block.xml) and the rest will be done
> automatically...
Sure, thanks for the clarification!
-Bertrand
Re: [osgi] Component management
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Niclas Hedhman wrote:
>On Tuesday 05 July 2005 23:15, Daniel Fagerstrom wrote:
>
><snip />
>
>I have nothing much to add to all your comments, other than I agree with every
>bit you mention.
>
>
>
>>That is a limiting factor ;), anyway its great to beeing able discuss
>>OSGi and component management with someone who allready has experience
>>in the field.
>>
>>
>
>I don't feel I have any experience. I am probablty pretty much at the same
>stage as you, Daniel. Reading the spec up and down, 4 times a day, trying to
>work out how some small detail is supposed to work.
>
>
>Right now I am struggling with getting my "artifact:" protocol to work
>together with classloaders inside the OSGi platform.
>
>I.e.
>
>I can do;
> URL url = new URL( "artifact:jar:log4j/log4j#1.2.8" );
> InputStream in = url.openStream();
> .... in.read(); ...
>
>with out problems, but if I do
> URL url = new URL( "artifact:jar:log4j/log4j#1.2.8" );
> URL[] urls = new URL[] { url };
> ClassLoader parent = getClass().getClassLoader();
> URLClassLoader ucl = new URLClassLoader( urls, parent );
> Class cls = ucl.loadClass( "org.apache.log4j.Logger" );
>
>
>I will get a ClassNotFoundException. (Same goes for any getResourceAsStream()
>).
>
>All of the above in Knopflerfish.
>
>I am starting to think that the Classloading mechanism doesn't not go through
>the registered URLStreamHandlerFactory that OSGi put in place.
>In any event, this detail have already taken 2 days and a lo of frustration
>:o)
>
>
Its not fun all the time, I have also spent some days at similar issues.
For your problem above, have you tried to set the context classloader as
described in: http://www.knopflerfish.org/programming.html#activator (a
page down or so), it solved my problems in a case similar to yours.
Also if you try to use the bundle: protocol between bundles, you need to
set the property
-Dorg.knopflerfish.osgi.registerbundleurlhandler=true
which is described in http://www.knopflerfish.org/changelog.html, but
not in an example in http://www.knopflerfish.org/programming.html that
doesn't work until you have set the above property.
Setting:
-Dorg.knopflerfish.framework.debug.classloader=true
helps a lot when you try to understand what the classloader do, and more
importantly not do ;)
/Daniel
Re: [osgi] Component management
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 05 July 2005 23:15, Daniel Fagerstrom wrote:
<snip />
I have nothing much to add to all your comments, other than I agree with every
bit you mention.
> That is a limiting factor ;), anyway its great to beeing able discuss
> OSGi and component management with someone who allready has experience
> in the field.
I don't feel I have any experience. I am probablty pretty much at the same
stage as you, Daniel. Reading the spec up and down, 4 times a day, trying to
work out how some small detail is supposed to work.
Right now I am struggling with getting my "artifact:" protocol to work
together with classloaders inside the OSGi platform.
I.e.
I can do;
URL url = new URL( "artifact:jar:log4j/log4j#1.2.8" );
InputStream in = url.openStream();
.... in.read(); ...
with out problems, but if I do
URL url = new URL( "artifact:jar:log4j/log4j#1.2.8" );
URL[] urls = new URL[] { url };
ClassLoader parent = getClass().getClassLoader();
URLClassLoader ucl = new URLClassLoader( urls, parent );
Class cls = ucl.loadClass( "org.apache.log4j.Logger" );
I will get a ClassNotFoundException. (Same goes for any getResourceAsStream()
).
All of the above in Knopflerfish.
I am starting to think that the Classloading mechanism doesn't not go through
the registered URLStreamHandlerFactory that OSGi put in place.
In any event, this detail have already taken 2 days and a lo of frustration
:o)
Cheers
Niclas
Re: [osgi] Component management
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
(I appologize upfront that I'm not explain all the involved concepts for
those not yet up to speed with OSGi ;) See this as some brainstorming. I
will try to write somthing more comprehensible and structured, when the
concepts gets clearer to me.)
Niclas Hedhman wrote:
>On Tuesday 05 July 2005 06:10, Daniel Fagerstrom wrote:
>
>
>>Niclas Hedhman wrote:
>>
>>
>>>running Metro (p.k.a Merlin) on top of OSGi, where the Avalon components
>>>are exposed as OSGi services as well as ServiceManager.lookup() resolves
>>>to OSGi services if no 'local implementations' within the Metro container
>>>exist.
>>>
>>>
>>Interesting indeed! I have thought about something like that for Cocoon.
>>I.e. handling all inter block (bundle) component lookup as OSGi
>>services. In this way one can use different component containers in
>>different blocks. Also such OSGi aware component containers would not
>>need to know anything about Cocoon and its interfaces.
>>
>>
>Yes, that sounds very reasonable, I would even dare to go one step further and
>say that I could implement a block without any component manager. If Cocoon
>Core exposes relevant services, which my block can hook into, it is from
>Cocoon's pespective fairly uninteresting how the functionality is achieved.
>
>
Exactly.
>>We would need to implement an own for ECM++ and other containers that we
>>like to support in the short time frame.
>>
>>
>
>This is about stepping on new turf, and I am sure it is not possible to have
>all the answers straight away. I think a couple of phases will occur, a) get
>the whole of existing Cocoon to be a Bundle,
>
Working on this right now in whiteboard/osgi. I use one Cocoon library
bundle that contains the cocoon.jar together with all needed jars (there
should be separate bundles for jars that are used by other blocks, but
that is a later question). One webapp bundle that contains the samples
and has "sitemap" as Bundle-Category. One cocoon_servlet bundle that
finds the "sitemap" bundle, creates a CocoonServlet and register it in
the http service.
> b) get that to deploy properly
>in Tomcat et al,
>
There can be some trickiness in getting that to work as servlet
containers and an OSGi server has some overlapping concerns, both want
to take care of Java security and classloading and both might try to
register new URL protocols, which only is allowed to be done once.
Servlet containers is neither my interest or something I have expertise
in, so I hope that others wih expertize and interest jump in and work on
this area. For my usecases I'm happy with using an OSGi http service,
the one based on Jetty e.g. http://oscar-osgi.sourceforge.net/repo/http/.
> c) get a block bundle to hook into the monolith,
>
For pure library bundles (i.e. whithout activator) that contains
components, one could have some solution where some ECM++ adapter bundle
searches for such bundles and serve them through the service manager as
today. But that requires exposing all classes of the library bundles. I
would prefer a solution like the one that we discussed above where the
component bundles (blocks) are "active" and register its components as
services. Then the component container within Cocoon core could look
through non-internal components through some blocks manager that request
the bundle context for services.
For blocks exposing sitemap functionality I would like them to register
some kind of sitemap or cocoon or even processor service that basically
exposes the o.a.c.Processor interface. This would follow the whiteboard
pattern where blocks register a cocoon service and a global blocks
manager detects the registration event and start to delgate appropriate
requests to it.
I would prefer to have the cocoon service or processor service exposing
as little Cocoon specifics as possible. That might make it possible to
base different blocks on different Cocoon versions or even to implement
processor services that not are related to Cocoon at all, but still
cooperates with other sitemap blocks.
> d) refactor
>out core parts that can be seen as optional into bundles, and so on... Many
>lessons will be learnt on the way, just like Cocoon of today has emerged from
>past experiences.
>
>
Yes.
>>Could you tell more about your architecture works? In particular how you
>>handle the hot plugability of bundles. Are you using dynamic proxies or
>>something like that
>>http://www.aqute.biz/2005/06/simple-osgi-components.html ?
>>
>>
>Not at the moment. I am depending on that the Bundle creator does his part
>properly. Whether to go with byte code manipulation, as suggested by Mr
>Kriens, or having something a bit more explicit is something to think about.
>My primary goal is to get Metro to work, and it has its own Proxy isolation
>between services already in place, so it is a matter of taking advantage of
>that.
>
>
Ok.
We don't need to get everything hot deployable and updatable at the
beginning, but it should be our long term goal. And explicit life cycle
handling for components that can be installed updated and removed at
every moment is tricky and error prone, so some kind of support for it
is necessary IMO.
>>>Lately, I have been working with an explicit custom management side. That
>>>means that each component is free to define its own management
>>>requirement, and optionally implement it if no existing pattern exists.
>>>That means that Pico and Spring *could* co-exist,
>>>
>>>
>>How do you handle that, any references?
>>
>>
>
>This started out with me and Stephen McConnell in the same room and my white
>board.
> http://www.dpml.net/about/notepad/freight/brainstorming.html
>which lead to this preliminary draft
> http://www.dpml.net/about/notepad/freight/development.html
>
>We use very little meta information, and rely on naming conventions. This is
>just a choice and less relevant.
>In the development.html page, it is not described that the ContextManager is
>assembled in build time and "packaged" together with the component. Again,
>implementation details probably not relevant in this context.
>
>
Seem interesting, especially I like that it puts more emphasis at Java
design pattern and less on some external container. Anyway, I should
stop asking about the details in this context, as we certainly not need
to change IOC strategy right now, rather isolate our current choice as
much as possible and make it as easy as possible for users to use what
they want to.
>>My view is to choose container at the block level, (the BundleActivator
>>could e.g. extend a PicoActivator).
>>
>>
>Yes, that could be reasonable. You may face problems to hook into the
>Pico/Spring internals though. I was not able to make what I wanted in Metro
>without touching the guts, i.e. changing the ServiceManager to understand the
>BundleContext for retrieval of external services, and changes to the 'Model'
>that Services are to be registered with OSGi. Not too hard, but right now
>creates a fork of the codebase, and I want to avoid that and that is a much
>bigger challenge.
>
>
Yes, the "ServiceManager" must be plugable to be able to achieve OSGi
service - component container integration. And that might not be the
case for some of the popular containers. For ECM++ it shouldn't be a
problem as we control it. And for other containers, I wouldn't be
suprised if there starts some OSGi hype in the near future when people
start to realize what one can do with Eclipse RCP etc, then more people
will like to use their favourite container whithin a bundle or plugin.
>>Second time I see a refernence to Context IOC
>>http://www.theserverside.com/articles/content/IOCandEJB/article.html,
>>this time when I read the article again, it started to make sense to me
>>;) Seems interesting.
>>
>>
>We have chosen to use a subset of the proposal in the above article. Reason
>being that it can become very confusing, and makes generic implementation
>fairly complicated.
>
>
Also got that impression.
>What is important to notice is that it improves testability quite a bit, and
>IMHO it communicates "intent" in the code fairly well, compared to anything
>else I have seen so far. And it is a pattern one can use without relying on
>containers, if one wants that.
>
>
Yes I also like it. It will be interesting to see what you produce.
>>>The fact that bundles can be loaded, then manipulated (config,
>>>permissions, ++) and finally the entire OSGi platform saved into a
>>>deployment bundle is also an interesting aspect.
>>>
>>>
>>I'm not certain that the Eclipse OSGi implementation does this.
>>
>>
>Well, maybe not out of the box, but the specification allows for it, and I am
>pretty sure their OSGi implementation don't break the spec intentionally.
>Also, the configurable parts must co-operate thru the ManagedService
>interface and the write back of config to the ServiceRegistration, and
>perhaps Eclipse have chosen not to use it in their bundles.
>
>
I refered to the persistense aspect, I got some impression that it
wasn't completely supported from the Eclispe mail list, but I don't
remember the details. I have no reason to doubt that it supports
ManagedService and other services.
>>>For Cocoon it should mean that all services that has configuration,
>>>should implement ManagedService and store all their config state in the
>>>ServiceRegistration. Which means one can tune the running server and no
>>>need to worry about that getting lost on restarts.
>>>
>>>
>>Note to other readers: This means that configurations are handled by a
>>certain Configuration admin service that is a standard service from
>>OSGi. Both Knopflerfish and Oscar has free implementations, of it.
>>
>>
>Yes. OTOH, nothing prevents someone from creating a bundle implementing the
>Config Admin Service, which in turn is a full Cocoon application with forms
>and stuff. And it can co-exist, co-run with other Config Admin Services.
>
>
Yes, that should be emphased, the standard services is a set of
interfaces that can be implemented in any way we like, if we happen to
want to use them. They make no assumption on using some particular
logging framework etc, while concrete implementations obviously do.
>>For the moment I don't know how much we should use standard services:
>>log service, configuration admin, URL handler service, http service etc.
>>I think we can decide this when we start to understand more about how
>>the architecture.
>>
>>
>I think that is a wise general principle. Once it is made, it is also not
>necessarily a final decision :o)
>
>
>
>>>BUT, it is easy to
>>>make mistakes keeping references to old instances in other bundles,
>>>causing all kinds of problems. So great care required! :o)
>>>
>>>
>>Not so cool. Hopefully we can provide infrastructure that help users
>>keeping track on the dependencies.
>>
>>
>Yes, the mentioned Proxy injection is probably something one should figure out
>at some point. Perhaps it is a matter of priority and demand more from the
>block developers initially, and then lax it later with better
>tools/techniques.
>
>
>IMHO, Cocoon has a lot of fun time ahead of itself, especially if this
>exercise can occur with disruption. Once some initial steps are taken, I
>think a fair bit of the Core internals can be 'migrated' away from ECM++ bit
>by bit, and a golden opportunity to increase the body mass of people having a
>clue how the core internals work ;o)
>
>
Definitively :)
>If I had more Cocoon work than I have, I would throw more cycles your way, but
>right now I need to concentrate on process control and industrial automation
>stuff. One have to eat :o)
>
>
That is a limiting factor ;), anyway its great to beeing able discuss
OSGi and component management with someone who allready has experience
in the field.
/Daniel
Re: [osgi] Component management
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 05 July 2005 06:10, Daniel Fagerstrom wrote:
> Niclas Hedhman wrote:
> > running Metro (p.k.a Merlin) on top of OSGi, where the Avalon components
> > are exposed as OSGi services as well as ServiceManager.lookup() resolves
> > to OSGi services if no 'local implementations' within the Metro container
> > exist.
> Interesting indeed! I have thought about something like that for Cocoon.
> I.e. handling all inter block (bundle) component lookup as OSGi
> services. In this way one can use different component containers in
> different blocks. Also such OSGi aware component containers would not
> need to know anything about Cocoon and its interfaces.
Yes, that sounds very reasonable, I would even dare to go one step further and
say that I could implement a block without any component manager. If Cocoon
Core exposes relevant services, which my block can hook into, it is from
Cocoon's pespective fairly uninteresting how the functionality is achieved.
> We would need to implement an own for ECM++ and other containers that we
> like to support in the short time frame.
This is about stepping on new turf, and I am sure it is not possible to have
all the answers straight away. I think a couple of phases will occur, a) get
the whole of existing Cocoon to be a Bundle, b) get that to deploy properly
in Tomcat et al, c) get a block bundle to hook into the monolith, d) refactor
out core parts that can be seen as optional into bundles, and so on... Many
lessons will be learnt on the way, just like Cocoon of today has emerged from
past experiences.
> Could you tell more about your architecture works? In particular how you
> handle the hot plugability of bundles. Are you using dynamic proxies or
> something like that
> http://www.aqute.biz/2005/06/simple-osgi-components.html ?
Not at the moment. I am depending on that the Bundle creator does his part
properly. Whether to go with byte code manipulation, as suggested by Mr
Kriens, or having something a bit more explicit is something to think about.
My primary goal is to get Metro to work, and it has its own Proxy isolation
between services already in place, so it is a matter of taking advantage of
that.
> > Lately, I have been working with an explicit custom management side. That
> > means that each component is free to define its own management
> > requirement, and optionally implement it if no existing pattern exists.
> > That means that Pico and Spring *could* co-exist,
>
> How do you handle that, any references?
This started out with me and Stephen McConnell in the same room and my white
board.
http://www.dpml.net/about/notepad/freight/brainstorming.html
which lead to this preliminary draft
http://www.dpml.net/about/notepad/freight/development.html
We use very little meta information, and rely on naming conventions. This is
just a choice and less relevant.
In the development.html page, it is not described that the ContextManager is
assembled in build time and "packaged" together with the component. Again,
implementation details probably not relevant in this context.
> My view is to choose container at the block level, (the BundleActivator
> could e.g. extend a PicoActivator).
Yes, that could be reasonable. You may face problems to hook into the
Pico/Spring internals though. I was not able to make what I wanted in Metro
without touching the guts, i.e. changing the ServiceManager to understand the
BundleContext for retrieval of external services, and changes to the 'Model'
that Services are to be registered with OSGi. Not too hard, but right now
creates a fork of the codebase, and I want to avoid that and that is a much
bigger challenge.
> Second time I see a refernence to Context IOC
> http://www.theserverside.com/articles/content/IOCandEJB/article.html,
> this time when I read the article again, it started to make sense to me
> ;) Seems interesting.
We have chosen to use a subset of the proposal in the above article. Reason
being that it can become very confusing, and makes generic implementation
fairly complicated.
What is important to notice is that it improves testability quite a bit, and
IMHO it communicates "intent" in the code fairly well, compared to anything
else I have seen so far. And it is a pattern one can use without relying on
containers, if one wants that.
> > The fact that bundles can be loaded, then manipulated (config,
> > permissions, ++) and finally the entire OSGi platform saved into a
> > deployment bundle is also an interesting aspect.
>
> I'm not certain that the Eclipse OSGi implementation does this.
Well, maybe not out of the box, but the specification allows for it, and I am
pretty sure their OSGi implementation don't break the spec intentionally.
Also, the configurable parts must co-operate thru the ManagedService
interface and the write back of config to the ServiceRegistration, and
perhaps Eclipse have chosen not to use it in their bundles.
> > For Cocoon it should mean that all services that has configuration,
> > should implement ManagedService and store all their config state in the
> > ServiceRegistration. Which means one can tune the running server and no
> > need to worry about that getting lost on restarts.
>
> Note to other readers: This means that configurations are handled by a
> certain Configuration admin service that is a standard service from
> OSGi. Both Knopflerfish and Oscar has free implementations, of it.
Yes. OTOH, nothing prevents someone from creating a bundle implementing the
Config Admin Service, which in turn is a full Cocoon application with forms
and stuff. And it can co-exist, co-run with other Config Admin Services.
> For the moment I don't know how much we should use standard services:
> log service, configuration admin, URL handler service, http service etc.
> I think we can decide this when we start to understand more about how
> the architecture.
I think that is a wise general principle. Once it is made, it is also not
necessarily a final decision :o)
> > BUT, it is easy to
> > make mistakes keeping references to old instances in other bundles,
> > causing all kinds of problems. So great care required! :o)
>
> Not so cool. Hopefully we can provide infrastructure that help users
> keeping track on the dependencies.
Yes, the mentioned Proxy injection is probably something one should figure out
at some point. Perhaps it is a matter of priority and demand more from the
block developers initially, and then lax it later with better
tools/techniques.
IMHO, Cocoon has a lot of fun time ahead of itself, especially if this
exercise can occur with disruption. Once some initial steps are taken, I
think a fair bit of the Core internals can be 'migrated' away from ECM++ bit
by bit, and a golden opportunity to increase the body mass of people having a
clue how the core internals work ;o)
If I had more Cocoon work than I have, I would throw more cycles your way, but
right now I need to concentrate on process control and industrial automation
stuff. One have to eat :o)
Cheers
Niclas
[osgi] Component management
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Was Re: [osgi] metadata
Niclas Hedhman wrote:
> (sorry for a bit lengthy mail)
> On Monday 04 July 2005 20:57, Daniel Fagerstrom wrote:
> <snip />
> Thanks for the clarification.
>>Niclas, are you getting up to speed with OSGi?
>
> Well, I am tugging along with OSGi independently of Cocoon.
> As you probably know, I am from the Avalon camp, and has been working on
> running Metro (p.k.a Merlin) on top of OSGi, where the Avalon components are
> exposed as OSGi services as well as ServiceManager.lookup() resolves to OSGi
> services if no 'local implementations' within the Metro container exist.
Interesting indeed! I have thought about something like that for Cocoon.
I.e. handling all inter block (bundle) component lookup as OSGi
services. In this way one can use different component containers in
different blocks. Also such OSGi aware component containers would not
need to know anything about Cocoon and its interfaces.
We would need to implement an own for ECM++ and other containers that we
like to support in the short time frame. But when it becomes popular to
develop applications in Eclipse, RCP http://www.eclipse.org/rcp/, Cocoon
with real blocks ;) etc, people outside our community will feel need for
using various Component Managers for intra block/bundle/plugin etc
component handling and implement such bundles.
The Cocoon core will probably need to depend on ECM++ for some time, but
the less we make block development depending on any particular
container, the better IMO.
--- o0o ---
Could you tell more about your architecture works? In particular how you
handle the hot plugability of bundles. Are you using dynamic proxies or
something like that
http://www.aqute.biz/2005/06/simple-osgi-components.html ?
> I am still struggling with some classloading issues. Not sure if it is
> Knopflerfish or the OSGi spec, but the Oscar documentation mentioned that
> OSGi has tightened up the specification around classloading, i.e. less
> permissive.
>
>>Any thoughts about how to
>>use modern component management together with OSGi?
>
> I am no longer sure what "modern component management" would be ;o)
> IMHO, Spring's extensive use of XML seems to me to transfer coding from Java
> to XML, and remove the type-safety of Java. They say noone has a problem with
> it, but I think that is hype.
Agree
> I don't have any experience myself with Pico as such, but use CDI (not
> automatic) a lot myself.
>
> Lately, I have been working with an explicit custom management side. That
> means that each component is free to define its own management requirement,
> and optionally implement it if no existing pattern exists. That means that
> Pico and Spring *could* co-exist,
How do you handle that, any references?
My view is to choose container at the block level, (the BundleActivator
could e.g. extend a PicoActivator).
> together with a pattern called ContextIOC
> which I find really intriguing (well, I find the "official" pattern a bit
> confusing, but one can boil that down to something with better clarity.)
Second time I see a refernence to Context IOC
http://www.theserverside.com/articles/content/IOCandEJB/article.html,
this time when I read the article again, it started to make sense to me
;) Seems interesting.
> Another aspect, is that it is possible to push a lot more of the so called
> "component management" over to "Build Time", and end up with "sealed
> components" that are already "resolved and configured". Such "sealed
> component" could end up as a Bundle for deployment, or even just a marshalled
> serialized binary ready to be put into action.
>
>
> All these are experiments that are being conducted and probably not relevant
> to Cocoon.
>
>
> Back to OSGi;
> The fact that bundles can be loaded, then manipulated (config, permissions,
> ++) and finally the entire OSGi platform saved into a deployment bundle is
> also an interesting aspect.
I'm not certain that the Eclipse OSGi implementation does this.
> For Cocoon it should mean that all services that has configuration, should
> implement ManagedService and store all their config state in the
> ServiceRegistration. Which means one can tune the running server and no need
> to worry about that getting lost on restarts.
Note to other readers: This means that configurations are handled by a
certain Configuration admin service that is a standard service from
OSGi. Both Knopflerfish and Oscar has free implementations, of it.
For the moment I don't know how much we should use standard services:
log service, configuration admin, URL handler service, http service etc.
I think we can decide this when we start to understand more about how
the architecture.
> I am still a long way from understanding all aspects of OSGi. But to me one
> thing is fairly clear; The platform specifications are well balanced,
> allowing for rock-solid implementations in the difficult domain of
> classloading management.
>
> I like it a lot. I like the way I end up developing, hitting reload button
> after a compile. I like to manipulate configs and permissions in runtime. I
> like that only a fraction of the application is reloaded.
I have the same experience this far.
> BUT, it is easy to
> make mistakes keeping references to old instances in other bundles, causing
> all kinds of problems. So great care required! :o)
Not so cool. Hopefully we can provide infrastructure that help users
keeping track on the dependencies.
/Daniel
Re: [osgi] metadata
Posted by Niclas Hedhman <ni...@hedhman.org>.
(sorry for a bit lengthy mail)
On Monday 04 July 2005 20:57, Daniel Fagerstrom wrote:
<snip />
Thanks for the clarification.
> Niclas, are you getting up to speed with OSGi?
Well, I am tugging along with OSGi independently of Cocoon.
As you probably know, I am from the Avalon camp, and has been working on
running Metro (p.k.a Merlin) on top of OSGi, where the Avalon components are
exposed as OSGi services as well as ServiceManager.lookup() resolves to OSGi
services if no 'local implementations' within the Metro container exist.
I am still struggling with some classloading issues. Not sure if it is
Knopflerfish or the OSGi spec, but the Oscar documentation mentioned that
OSGi has tightened up the specification around classloading, i.e. less
permissive.
> Any thoughts about how to
> use modern component management together with OSGi?
I am no longer sure what "modern component management" would be ;o)
IMHO, Spring's extensive use of XML seems to me to transfer coding from Java
to XML, and remove the type-safety of Java. They say noone has a problem with
it, but I think that is hype.
I don't have any experience myself with Pico as such, but use CDI (not
automatic) a lot myself.
Lately, I have been working with an explicit custom management side. That
means that each component is free to define its own management requirement,
and optionally implement it if no existing pattern exists. That means that
Pico and Spring *could* co-exist, together with a pattern called ContextIOC
which I find really intriguing (well, I find the "official" pattern a bit
confusing, but one can boil that down to something with better clarity.)
Another aspect, is that it is possible to push a lot more of the so called
"component management" over to "Build Time", and end up with "sealed
components" that are already "resolved and configured". Such "sealed
component" could end up as a Bundle for deployment, or even just a marshalled
serialized binary ready to be put into action.
All these are experiments that are being conducted and probably not relevant
to Cocoon.
Back to OSGi;
The fact that bundles can be loaded, then manipulated (config, permissions,
++) and finally the entire OSGi platform saved into a deployment bundle is
also an interesting aspect.
For Cocoon it should mean that all services that has configuration, should
implement ManagedService and store all their config state in the
ServiceRegistration. Which means one can tune the running server and no need
to worry about that getting lost on restarts.
I am still a long way from understanding all aspects of OSGi. But to me one
thing is fairly clear; The platform specifications are well balanced,
allowing for rock-solid implementations in the difficult domain of
classloading management.
I like it a lot. I like the way I end up developing, hitting reload button
after a compile. I like to manipulate configs and permissions in runtime. I
like that only a fraction of the application is reloaded. BUT, it is easy to
make mistakes keeping references to old instances in other bundles, causing
all kinds of problems. So great care required! :o)
Cheers
Niclas
Re: [osgi] metadata
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Niclas Hedhman wrote:
>On Monday 04 July 2005 17:25, Reinhard Poetz wrote:
>
>
>>I'm a bit confused about the relation between import/export package and
>>Require-Bundle. Does anybody know about this?
>>
>>
>
>Is this R4 or Eclipse? I can't find it in R3 spec.
>
>By the sound of it, "Require-Bundle X" means that the bundle will not be
>started without the "X Bundle" being present. A kind of "Must Have"
>dependency. And the import is the "normal" "Would Like To Have" dependency,
>understood implicitly that the bundle will work without it (work being fairly
>loose description).
>
>
I gave some links about this in my answer to Reinhard. It is a little
bit more flexible with than you guess above, but not much. Although it
might seem atractive to depend on whole bundles instead of on a bunch of
packages it seem to lock the dependecy on a certain implementation.
Cf with:
"One very important difference between OSGi and Eclipse is on dependencies.
OSGi expresses dependencies on imported packages (name and version), but not
on which bundle actually exports them. In other words, in OSGi, any set of
bundles can replace another set of bundles as long as the Java packages they
export are the same (name and version). In Eclipse, dependencies are
expressed on plug-ins. So Eclipse bounds plug-ins explicit together,
providing no separation between a plug-in API and its implementation."
from an early discussion about using OSGi as base for Eclipse
http://dev.eclipse.org/newslists/news.eclipse.technology.equinox/msg00039.html,
that I cited in an earlier mail.
The Require-Bundle dependency has AFAICS no correspondance to the
interface blocks that are part of the blocks design. OTH something close
to the intended behaviour can be achieved by creating an interface
bundle that put all of the its interfaces in one exported package.
So while declaring dependencies at the package level rather than the
block level isn't exactly what is specified in the blocks design, it has
as you can see above some advantages, and by using some coding
conventions we can get the same behaviour.
--- o0o ---
Niclas, are you getting up to speed with OSGi? Any thoughts about how to
use modern component management together with OSGi?
/Daniel
Re: [osgi] metadata
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 04 July 2005 17:25, Reinhard Poetz wrote:
> I'm a bit confused about the relation between import/export package and
> Require-Bundle. Does anybody know about this?
Is this R4 or Eclipse? I can't find it in R3 spec.
By the sound of it, "Require-Bundle X" means that the bundle will not be
started without the "X Bundle" being present. A kind of "Must Have"
dependency. And the import is the "normal" "Would Like To Have" dependency,
understood implicitly that the bundle will work without it (work being fairly
loose description).
Cheers
Niclas
Re: [osgi] metadata
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Reinhard Poetz wrote:
>>
>>> I still like the idea of automatically generating the OSGi manifest
>>> :-). All the general properties (author, documentation, ...) are
>>> available in block.xml
>>
>>
>>
>> Yes, OTH, I believe that it is in general an anti pattern to have two
>> reduntant versions of essentially the same info. Considering the
>> popularity of Eclipse, there will be many people that have experience
>> with OSGi manifest files, and that will find it confusing to specify
>> esentially the same info somewhere else. Also take into account that
>> the Eclipse developers decided to deprecate parts of pluggin.xml,
>> which is rather well spread, in the interest of avoiding redundancy.
>> As nothing, except for some experimental code and some webpages is
>> dependent on the format of block.xml we have far less restrictions
>> than they have.
>
>
> Are you proposing to skip block.xml and only have the OSGi manifest or
> reducing block.xml and putting every redundant piece of information
> into the OSGi manifest?
The later, let the OSGi manifest package dendencies and what happens to
be part of the manifest. Then block.xml specifies whats need to be
specified at the component level and sitemap level.
IMO we should make it easy for the Cocoon blocks to coexist and
colloborate with "pure" bundles (without any Cocoon dependencies) or
Eclipse plugins (if you deploy the needed Eclipse framework bundles).
But it becomes rather abstract to discuss how to split (or not) the
configuration files at this point. We have to let that develop while we
get more experience from implementing the different layers.
> I don't think that those general meta information are the real problem
> but the dependency information. The declared dependencies should be
> the same for the OSGi layer, component management and the sitemap
> layer. Declaring them twice will lead to a big mess.
>
>>> and the information about the exported packages can also be
>>> generated if we seperate between public (exported) and internal
>>> classes and libraries within our directory structure.
>>>
>>> [block]
>>> - src
>>> - java
>>> - public
>>> com/mycompany/project/xyz
>>> ...
>>> - internal
>>> com/mycompany/project/xyz/impl
>>> ...
>>> - lib
>>> - public
>>> - internal
>>>
>>> The information about the imported packages can be looked up in the
>>> OSGi manifest of the required block, again at build time.
>>
>>
>>
>> Yes, in some ideal case this would be nice. But given that our
>> current set of blocks doesn't fullfill any such standards we
>> propbably have to do a lot of exports and imports by hand.
>
>
> here we will have to do a lot of refactoring in any case as we have to
> adapt our package name structure IIU OSGi and one of your previous
> mails correctly. Moving around some packages will not be the problem
> (with SVN and Eclipse).
That's true. What I meant is that we for some of the current blocks and
for the Cocoon core might need to have back compatible solutions with
package structure that is less easy to automatically export and import.
>> Automatically importing things that one don't need from another block
>> is not necessarilly a good idea as it imposes more constraints than
>> necessary and make it harder to change dependecies if one want to.
>
> if it's only about the Import-Package property than I'd say that we
> should include them into block.xml as _I_ prefer XML for properties.
> Using some XML editor that supports XML schema (e.g. OxygenXML) will
> make editing the block descriptor very easy.
I also like XML, but not as much as I dislike unnecessary redundancy ;)
>>> In short, I think that we (usually) don't have to put import/export
>>> packages information into it.
>>> Of course, keeping the OSGi manifest and block.xml seperate is
>>> always an option. Making the block build process handle both
>>> scenarios shouldn't be difficult.
>>>
>>> ---
>>>
>>> I'm a bit confused about the relation between import/export package
>>> and Require-Bundle. Does anybody know about this?
>>
>>
>>
>> Require-Bundle is part of Eclipse and possibly of OSGi R4 see
>> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/runtime/runtime.html
>> and https://bugs.eclipse.org/bugs/show_bug.cgi?id=82855.
>
>
> thanks, will read it (I think we should create a wiki page with all
> the OSGi information we (you) have collected so far)
Sounds like a good idea ;)
/Daniel
Re: [osgi] metadata
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> if it's only about the Import-Package property than I'd say that we
> should include them into block.xml as _I_ prefer XML for properties.
> Using some XML editor that supports XML schema (e.g. OxygenXML) will
> make editing the block descriptor very easy.
sorry, that could be mis-interpreted. Just wanted to say that I personally
prefer working with XML property files. If the majority here has another opinion
I can live with that ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [osgi] metadata
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>> I still like the idea of automatically generating the OSGi manifest
>> :-). All the general properties (author, documentation, ...) are
>> available in block.xml
>
>
> Yes, OTH, I believe that it is in general an anti pattern to have two
> reduntant versions of essentially the same info. Considering the
> popularity of Eclipse, there will be many people that have experience
> with OSGi manifest files, and that will find it confusing to specify
> esentially the same info somewhere else. Also take into account that the
> Eclipse developers decided to deprecate parts of pluggin.xml, which is
> rather well spread, in the interest of avoiding redundancy. As nothing,
> except for some experimental code and some webpages is dependent on the
> format of block.xml we have far less restrictions than they have.
Are you proposing to skip block.xml and only have the OSGi manifest or reducing
block.xml and putting every redundant piece of information into the OSGi manifest?
I don't think that those general meta information are the real problem but the
dependency information. The declared dependencies should be the same for the
OSGi layer, component management and the sitemap layer. Declaring them twice
will lead to a big mess.
>> and the information about the exported packages can also be generated
>> if we seperate between public (exported) and internal classes and
>> libraries within our directory structure.
>>
>> [block]
>> - src
>> - java
>> - public
>> com/mycompany/project/xyz
>> ...
>> - internal
>> com/mycompany/project/xyz/impl
>> ...
>> - lib
>> - public
>> - internal
>>
>> The information about the imported packages can be looked up in the
>> OSGi manifest of the required block, again at build time.
>
>
> Yes, in some ideal case this would be nice. But given that our current
> set of blocks doesn't fullfill any such standards we propbably have to
> do a lot of exports and imports by hand.
here we will have to do a lot of refactoring in any case as we have to adapt our
package name structure IIU OSGi and one of your previous mails correctly. Moving
around some packages will not be the problem (with SVN and Eclipse).
> Automatically importing things that one don't need from another block is
> not necessarilly a good idea as it imposes more constraints than
> necessary and make it harder to change dependecies if one want to.
if it's only about the Import-Package property than I'd say that we should
include them into block.xml as _I_ prefer XML for properties. Using some XML
editor that supports XML schema (e.g. OxygenXML) will make editing the block
descriptor very easy.
>> In short, I think that we (usually) don't have to put import/export
>> packages information into it.
>> Of course, keeping the OSGi manifest and block.xml seperate is always
>> an option. Making the block build process handle both scenarios
>> shouldn't be difficult.
>>
>> ---
>>
>> I'm a bit confused about the relation between import/export package
>> and Require-Bundle. Does anybody know about this?
>
>
> Require-Bundle is part of Eclipse and possibly of OSGi R4 see
> http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/runtime/runtime.html
> and https://bugs.eclipse.org/bugs/show_bug.cgi?id=82855.
thanks, will read it (I think we should create a wiki page with all the OSGi
information we (you) have collected so far)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [osgi] metadata
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Reinhard Poetz wrote:
>> <snip/>
>>
>>> Just want to mention that I don't think that our users need to know
>>> about OSGi at all if they don't want. They have to describe their
>>> block in the descriptor (block.xml) and the rest will be done
>>> automatically.
>>
>>
>>
>> Maybe or maybe not ;) The OSGi manifest is mainly about exporting and
>> importing Java packages, which are concerns that we haven't discussed
>> in any detail for the block descriptor. We could put this info in the
>> block.xml and generate the manifest file automatically from it.
>>
>> In Eclipse they didn't go that way. There was some info in their
>> pluggin descriptor that overlapped with the OSGi manifest. They
>> depreciated this infor from the pluggin descriptor and recommend
>> people to use the OSGi manifest instead. I would prefer that we do
>> the same and consider the OSGi manifest and the block.xml as taking
>> care of different concerns.
>
>
> I still like the idea of automatically generating the OSGi manifest
> :-). All the general properties (author, documentation, ...) are
> available in block.xml
Yes, OTH, I believe that it is in general an anti pattern to have two
reduntant versions of essentially the same info. Considering the
popularity of Eclipse, there will be many people that have experience
with OSGi manifest files, and that will find it confusing to specify
esentially the same info somewhere else. Also take into account that the
Eclipse developers decided to deprecate parts of pluggin.xml, which is
rather well spread, in the interest of avoiding redundancy. As nothing,
except for some experimental code and some webpages is dependent on the
format of block.xml we have far less restrictions than they have.
> and the information about the exported packages can also be generated
> if we seperate between public (exported) and internal classes and
> libraries within our directory structure.
>
> [block]
> - src
> - java
> - public
> com/mycompany/project/xyz
> ...
> - internal
> com/mycompany/project/xyz/impl
> ...
> - lib
> - public
> - internal
>
> The information about the imported packages can be looked up in the
> OSGi manifest of the required block, again at build time.
Yes, in some ideal case this would be nice. But given that our current
set of blocks doesn't fullfill any such standards we propbably have to
do a lot of exports and imports by hand.
Automatically importing things that one don't need from another block is
not necessarilly a good idea as it imposes more constraints than
necessary and make it harder to change dependecies if one want to.
> In short, I think that we (usually) don't have to put import/export
> packages information into it.
> Of course, keeping the OSGi manifest and block.xml seperate is always
> an option. Making the block build process handle both scenarios
> shouldn't be difficult.
>
> ---
>
> I'm a bit confused about the relation between import/export package
> and Require-Bundle. Does anybody know about this?
Require-Bundle is part of Eclipse and possibly of OSGi R4 see
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/runtime/runtime.html
and https://bugs.eclipse.org/bugs/show_bug.cgi?id=82855.
/Daniel
[osgi] metadata
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> <snip/>
>
>> Just want to mention that I don't think that our users need to know
>> about OSGi at all if they don't want. They have to describe their
>> block in the descriptor (block.xml) and the rest will be done
>> automatically.
>
>
> Maybe or maybe not ;) The OSGi manifest is mainly about exporting and
> importing Java packages, which are concerns that we haven't discussed in
> any detail for the block descriptor. We could put this info in the
> block.xml and generate the manifest file automatically from it.
>
> In Eclipse they didn't go that way. There was some info in their pluggin
> descriptor that overlapped with the OSGi manifest. They depreciated this
> infor from the pluggin descriptor and recommend people to use the OSGi
> manifest instead. I would prefer that we do the same and consider the
> OSGi manifest and the block.xml as taking care of different concerns.
I still like the idea of automatically generating the OSGi manifest :-). All the
general properties (author, documentation, ...) are available in block.xml and
the information about the exported packages can also be generated if we seperate
between public (exported) and internal classes and libraries within our
directory structure.
[block]
- src
- java
- public
com/mycompany/project/xyz
...
- internal
com/mycompany/project/xyz/impl
...
- lib
- public
- internal
The information about the imported packages can be looked up in the OSGi
manifest of the required block, again at build time.
In short, I think that we (usually) don't have to put import/export packages
information into it.
Of course, keeping the OSGi manifest and block.xml seperate is always an option.
Making the block build process handle both scenarios shouldn't be difficult.
---
I'm a bit confused about the relation between import/export package and
Require-Bundle. Does anybody know about this?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [Blockathon] agenda proposal
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
<snip/>
> Just want to mention that I don't think that our users need to know
> about OSGi at all if they don't want. They have to describe their
> block in the descriptor (block.xml) and the rest will be done
> automatically.
Maybe or maybe not ;) The OSGi manifest is mainly about exporting and
importing Java packages, which are concerns that we haven't discussed in
any detail for the block descriptor. We could put this info in the
block.xml and generate the manifest file automatically from it.
In Eclipse they didn't go that way. There was some info in their pluggin
descriptor that overlapped with the OSGi manifest. They depreciated this
infor from the pluggin descriptor and recommend people to use the OSGi
manifest instead. I would prefer that we do the same and consider the
OSGi manifest and the block.xml as taking care of different concerns.
Concerning what the users will need to know, I would assume that most
users today doesn't know that much about the current "compile time"
block system as we haven't documented how it is used or given any
promisses at all about the stability of the "contracts", i.e. gump
snippets and ant related stuff. So today I would guess that rather few
users develop own blocks. With the arrival of real blocks this will
change and users who want to develop own blocks must of course learn
something new. Much as one have to learn some new things to be able to
develop an Eclipse plugin.
Of course we all have interest in making at easy as possible to develop
new blocks and also to provide tool support for making it easy. I just
want to emphasize that the real blocks not is so much about changing how
things work today (something we should try to avoid), but mainly about
*adding* new and more convenient ways to work.
/Daniel
Re: [Blockathon] agenda proposal
Posted by Reinhard Poetz <re...@apache.org>.
Bertrand Delacretaz wrote:
> Le 4 juil. 05, à 07:38, Reinhard Poetz a écrit :
>
>> ...We both think that placing Cocoon on the top of OSGi should be our
>> main goal...
>
>
> Hmm..dare I say "create an exploratory prototype of Cocoon running on
> top of OSGI" instead?
yes, that's better and closer to that what we mean. Danniel and I are confident
that OSGi will be a good solution but this is still unproven. We would like to
see a prototyp running after the 3 days so that we have something to decide and
discuss about. As we have seen, further discussions on technical details don't
bring as forward any more.
> I totally agree with the idea, it's just that we don't want to scare our
> users too much before there is concrete evidence that this will work ;-)
Just want to mention that I don't think that our users need to know about OSGi
at all if they don't want. They have to describe their block in the descriptor
(block.xml) and the rest will be done automatically.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [Blockathon] agenda proposal
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
> Le 4 juil. 05, à 07:38, Reinhard Poetz a écrit :
>
>> ...We both think that placing Cocoon on the top of OSGi should be our
>> main goal...
>
> Hmm..dare I say "create an exploratory prototype of Cocoon running on
> top of OSGI" instead?
Of course you dare ;) My hope is that I will be able to get an
"exploratory prototype" runing in the OSGi whiteboard, before the start
of the Blockathon. Much of what needs to be done after that has to do
with integrating it with our build system, blocks, scripts, component
handling and so on. These are things that are unpractical to do in a
whiteboard, so I would prefer to move the OSGi stuff to the trunk as
soon as we see that it works.
I would like the Blockathon to go further than exploratory prototyping.
> I totally agree with the idea, it's just that we don't want to scare
> our users too much before there is concrete evidence that this will
> work ;-)
I don't think there is anything in this that should scare the users. As
I have expressed repeatedly the trunk should be compilable and runable
at every moment. And the OSGi stuff shouldn't affect the way users
currently do things, although it will give them more convenient ways to
do things.
IMO its mainly the developers who need to be afraid ;) There will be new
things that we need to learn. And we are not going to get "real blocks"
whithout changing some internals and spend some work on getting it done.
> Apart from that I like the plan. I'll join you guys on the Monday,
> will read about OSGI on the train to try and catch up quickly!
/Daniel
Re: [Blockathon] agenda proposal
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 juil. 05, à 07:38, Reinhard Poetz a écrit :
> ...We both think that placing Cocoon on the top of OSGi should be our
> main goal...
Hmm..dare I say "create an exploratory prototype of Cocoon running on
top of OSGI" instead?
I totally agree with the idea, it's just that we don't want to scare
our users too much before there is concrete evidence that this will
work ;-)
Apart from that I like the plan. I'll join you guys on the Monday, will
read about OSGI on the train to try and catch up quickly!
-Bertrand