Ralph Goers wrote:
Daniel Fagerstrom said:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
<snip rt/>
I'm mostly fine with your proposed changes if you think that this helps
Cocoon. In the end all changes that don't require to rewrite or change
our current blocks are fine for me.
It will mean some changes for the portal block as it use the Cocoon
component and the same complicated setup as the the CocoonServlet.
Geting a component container that is setup by a servlet context listener
through the portlet context should work fine a simplify the portlet
setup as well.
Please provide an example of what this would look like. I really need to
understand how this will simplify anything.
But I'm remaining very sceptical wrt to a 2.2 release in general. I
think one of our main goals is currently out of focus: release early,
release often. This has nothing to do with this RT specifically, I just
wanted to use this thread as a reminder to focus on a release :)
My personal goal is to release a blocks based Cocoon. But if anyone want
to release something from trunk earlier, I'm fine with that. I just
don't see any activity in that direction.
While true, it is unfortunate. Switching to Maven 2 for building projects
is a lot less scary than switching from 2.1 to an OSGi based system. That
doesn't make it bad, but it may make the resistance to adopt it high. I
believe that is why it was recommended at the gettogether that the focus
be on delivering trunk with Maven 2 by the end of the year and then
focusing on "real blocks". At least, that is what I remember hearing.
The important differences between 2.1 and trunk is in the cocoon-core,
and as long as it is as complicated as it is today, only a few people
understand it well enough to be able to work on it. So refactorings that
make the core easier to understand and less monolithic will make it
easier for more people to get involved, which IMO should increase the
chance for a release.
For me, this remains to be seen. Moving stuff from cocoon's core to OSGi
doesn't make it any less complicated. It just makes it a different set of
things to understand. And unless you are getting rid of caching,
pipelines, etc. there is still a lot of Cocoon specific stuff to
understand.
Frankly, if trunk was completely working with Maven 2 I'd be all over it
trying to get it into production. But since it has been in sandbox mode
for so long, I've focused completely on 2.1 as that is what my employer
will be using until trunk gets in a mode where I trust it. And I don't
see much point in learning how trunk works until it stabilizes.
Ralph,
I can't follow your argumentation anymore. How do the following statements fit
together?
"Please provide an example of what this would look like. I really need to
understand how this will simplify anything."
and
"And I don't see much point in learning how trunk works until it stabilizes."
... so what do you want? Daniel and I spend our spare time on improving trunk
and this takes time as nobody is paying us directly for this because we do it in
our spare time. We have a clear goal and we communicated it dozens of times to
the list and added all open tasks to JIRA.
If this is too slow or insufficent for your needs, you need to get involved by
getting your hands dirty. You're complaining that things in trunk don't work as
they should? Hey, that's your chance! I don't think that it's rocket science to
improve things.
- o -
*If* you had took the time to learn a bit more about the architecture that
Daniel is proposing, you would learn that our work on OSGi isn't affecting the
non-OSGi-Cocoon in any way. Look at the current way of setting up Cocoon:
"[...] The CocoonServlet creates a CoreUtil which creates a CocoonBeanFactory
which in turn is used to get the Cocoon component, which in turn delegates most
of it job to the SitemapLanguage which also is a component that is managed by
the CocoonBeanFactory. A fun exercise for the interested is to try to figure out
how and where the Cocoon component is configured and created. [...]"
Daniel's proposal was about making this process simpler and this has *nothing*
to do with OSGi. Daniel and I believe that OSGi is the way to go but this
doesn't necessarily mean that everything we do is OSGi-related. As we had to
understand Cocoon internals in greater detail, we started to think more and more
about how to simplify things, and believe me, there is room for improvment as
the core of Cocoon has grown and got too complicated over the years.
--
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
