Daniel Fagerstrom wrote:
Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
It starts to look like a 3.0 rather than a 2.2 and my personal goal is
to implement the whole blocks design including OSGi. OTH I try to not
hinder the possibility for a 2.2 release, given that someone is prepared
to spearhead it.
Question is is there an interim "thing" that we can release before whole
OSGi is implemented? We were talking about an RC when Maven build was
done, but we seem to be moving away from that.
Sure there are a number possible interim things.
We can release more or less as is, what is lacking is a Maven
correspondence of the block.properties file and a plugin that collect
and install the configuration snippets in the blocks to the webapp.
I'm working on that and the design of the block deployer already supports
property replacement. Only the implementation is missing but will come soon.
We can also release with non OSGi blocks. The blocks are ongoing work,
the most important thing that lacks is "two level configuration". As
discussed before the component configuration is part of the block and
constant, so they need to be parametrized in some way for making them
user configurable. We have not had much discussion about how to do this
yet.
My understanding is that a user can parameterize a block at deployment (which is
supported by the block deployer) if he wants. Otherwise the default values are
taken.
Also the APIs and concepts for blocks need to actually be used for some
real life examples before we can be convinced that we got it right.
Of course. I'm working on getting trunk as far as making it very simple to use
it for custom projects. Then I will start to rework at least one of my projects
to use blocks and learn more about their real life usage. We should make it easy
that at least we developers (and some brave users) can start to experiment.
Gradual steps, release often is good.
Agree, but as it will be the first release from trunk the threshold is
higher.
IMO we should consolidate the current status and make trunk useable for projects
again which should result in agreeing on our external contracts.
Making life harder for future
exciting developments by releasing too early isn't good.
Exactly, one point i that trunk contains nice mechanisms for
parameterizing components and sitemaps at a global level and also for
having foreign component managers within sitemaps. While very usefull
for the current development style in Cocoon they are not very relevant
for blocks. For blocks we should avoid global configurations as it is in
the way for splitting Cocoon in small reusable parts. And also component
configurations in sitemaps is rather unnecessary when we have component
configurations on the block level.
So what should we do about introducing things that we know that we will
want to remove in a later release?
As long as we have milestone releases, I have no problem with sitemap
classloaders and sitemap application containers. If both features become block
functionality, people have to migrate. (IIRC also Eclipse had some incompatible
changes in their 3.0 milestone series.)
If this is the case, then it would seem timely to improve these
interfaces now, as 2.2 given the greater flexibility could become _the_
future Cocoon, and we may miss the boat if we don't make this change
now.
Yes, I feel some urgency. With enough focus and dedication on
refactoring Cocoon and finish the blocks Cocoon can be the Rich Server
Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And
regain its momentum. Focusing on 2.2 seem more like losing valuable time
for me.
Well, define 2.2 :-)
I presume you mean releasing a Maven based Cocoon without a ready blocks
system would loose valuable momentum.
Yes.
Do you have a roadmap on what's open?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
