On 12 Oct 2005, at 15:21, Daniel Fagerstrom wrote:
Pier Fumagalli wrote:On 12 Oct 2005, at 12:40, Daniel Fagerstrom wrote:Pier Fumagalli wrote:On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote:Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns.I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain.And I know a lot of others share my concerns (from discussions at the GT).Any specific concerns about OSGi?Personally, it looks "cumbersome" to me... Heck, I'm writing an Eclipse plugin at the moment, and if it wasn't for the Eclipse Plugin editor and stuff, I'd be totally lost.OSGi gives us classloader isolation and the possibility of hot plugabillity. Both are rather complex areas, and things that we require from the real block system, so some extra complexity is hard to avoid.
Classloader isolation is quite neat, I have to admit that, but it's not a major difficulty to implement on top of existing frameworks...
An advantage of using OSGi instead of a home brewn solution is that we don't have to solve all these complexity issues ourselves. As an example there actually allready was an Eclipse plugin editor there that helped you.
On that I agree wholeheartedly, mate... Don't get me wrong.I'm just seeing my OSGI Eclipse plugin on one side, and the last slide Arje posted during the wrap-up of the GetTogether.... "SIMPLICITY" :-) Somehow, I can't feel OSGI is moving us towards that direction...
But that's a feeling, I'm far from saying "No, let's use something else", don't get me wrong...
Since the flow came along, I got quite lazy (weakly typed languages rule) and the complexity of writing (and maintaining) a set of metadata files related to each individual block, on top of sitemaps, wirings, xconfs, source Java files and so on is definitely not appealing to me.For the Manifest.mf, the only complexity I have experienced is maintaining the export and import of packages. There are several things to say about that: First there are tool support to help you, Eclipse e.g. There is also a tool for calculating dependencies between the bundles: http://oscar-osgi.sourceforge.net/mangen/, that we maybe could use in our build process. You can also simplify export and import rules by using wildcards.But IMO there is a more important aspect of imports and exports: they declare what your bundle export and import and if they are complicated, that often mean that your bundle doesn't have a focused concern area and that its interface to the rest of the world is fat. This leads to rigid systems that are hard to reuse. So it is true that the current "bundleization" of Cocoon have complicated export and import section. I don't see that as a problem with OSGi, but rather as a consequnce of what we all allready know: Cocoon is monolothic, have far to much inter dependencies and fat interfaces and it is not that well defined what sub parts there are.
Yep... I feel your pain...But thinking about it for a little bit, I'm starting to wonder if there is another way...
There is still a big nag in my mind, related to what Leo posted a while ago, and outlined here: http://www.betaversion.org/~pier/ 2005/07/dependancies-through-import-statements.html
I like the simplicity that Leo outlined...
As soon as the basic mechanisms are in place I and hopefully others will focus on geting the contracts leaner.
Yep... We need to see what the future holds...
I'm wondering if there isn't an easier (simpler) way to approach the problem.Sure, don't we all ;) We can of course wait for ever on the perfect approach for real block. But after having waited for the for 3+ years, I and some others wanted something good enough now rather than something perfect in the future.For your core, you might remeber that I supported that we should use it and wanted to start working on it, but you never found time to answer my qustions about some of the concepts in it or commit the much improved version of it that you said that you had.
Dude, your pain is _my_ pain on this topic... Unfortunately my current job doesn't allow me to spend much time on Cocoon itself and related projects (or even on my wife, for that matters!!!).
Seriously speaking, I wish I could dedicate more time onto this, but for now, I'm tied into writing XSLT and maintaining a huge lump of PERL code, and I can tell you, it's not fun...
That's why I'm not saying "let's move away from OSGI", but just outlining the fact that I personally find it quite cumbersome, and that what I like most is simplicity...
If we go down the OSGI route, I'll code for OSGI, not for some pseudo-adapter of some sort... I'm not one to take shortcuts.I can agree with that attitude, even if I think most users will be quite happy to be able to use their favorit component container.
You know how I am :-) I don't like hacks, or one-fits-all things...
I just wish I had more time! :-P
Pier
smime.p7s
Description: S/MIME cryptographic signature
