cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Releasing Cocoon 2.2, finally!
Date Thu, 06 Mar 2008 21:24:34 GMT
Reinhard Poetz pisze:
> It's time to release Cocoon 2.2, finally! We have been working on it for
> years and I think it's time to ship the *final* release. I want to do
> this in three phases:
> 1) During the first phase I will release our two sub-projects "Cocoon
> Configuration" and "Cocoon Servlet-Service-Framework". This time I will
> create the Maven 2 release artifacts and "normal" zip/tar release
> artifacts for non-Maven users.
> I think that I will be able to finish it by the end of next week.

There is a subtle problem I discovered few days ago but I haven't reported up to date because
hadn't enough free time to confirm if this problem really exist. Anyway, I think that
cocoon-servlet-service-impl is not really Cocoon-independent because of this line:

  resolver = (SourceResolver) factory.getBean(SourceResolver.ROLE);

of getResource() method from ServletServiceContext class. The problem I can see here is that
cocoon-servlet-service-impl is used outside the Cocoon there is no default implementation
SourceResolver registered as a Spring bean. It's not a big deal, because Excalibur provides
implementation but we would need to figure out how to register and properly set up this component.

Actually, I see whole getResource() method flawed because it calculates contextPath when used
time and I think this code should belong to the setup (not runtime) phase of ServletServiceContext.
I already tried to move this code (I paste the patch at the end of this e-mail) but stumbled
some NPEs for specific servlet bean configurations and I haven't had enough free time to dig
this. I planned to take care of it during upcoming weekend because I finally get done with
all these
exams at my university.

The root motivation for me taking a look at this code was some experimentation with Micro
Specifically, I tried to make CocoonSourceResolver casual Spring bean and due to flawed contextPath
initialization I ran into cyclic dependency chain.

To be honest, I don't have an idea if we should consider this a blocker. I lean towards not
considering this a blocker but once we sort this out we will need to release 1.1.0 version
cocoon-servlet-service-impl. If I come up with the fix until Monday, do you think it's a good
to commit it just before final release? (I think it shouldn't harm and I would give it very
throughout testing)

> 2) The second phase is Cocoon Core and all the blocks that were released
> as release candidates. Additionally I want to release the Cocoon Maven
> plugin (milestone 2), the Cocoon integration test framework (milestone
> 1), our archetypes and a starter package for non-Maven users.
> Again, this time I will create "normal" zip/tar release artifacts,
> except those cases where it doesn't make sense (e.g. the Maven plugin,
> the POM artifacts and the archetypes).
> I think that I will manage to finish this work by the end of March.
> 3) The third phase is releasing our samples. It would be great if
> somebody else could help out with this task because I don't know if I
> will have the necessary cycles anytime soon. I guess that there is some
> work left in order to get this done and there are a couple of things to
> be discuessed before:
>  . What do we want to ship? A WAR file only, or a WAR file + a
> pre-configured
>    Jetty packaged as ZIP, etc?
>  . Do we ship snapshots of our blocks and samples? Or the released
> blocks and
>    the snapshots of the samples? Or do we want to release our samples
> offically?
>  . Are there any open legal issues? (e.g. we have to make sure that all the
>    licenses of 3-party libs are added, etc.)
>  . Or, should we only provide nightly snapshots of our samples? (though
> we would
>    still have to check what this means legally for us ...)
>  . etc.
>                                      - o -
> I know that there are still open isses but I don't see any blockers.
> Since this will probably be the last time when our sub-projects, core
> and a lot of blocks are released together, I think it will be easy to
> ship upgrades of one module as soon as we have something better
> available without having to wait for all the rest getting stable.
> As soon as I'm ready for the actual release work, I will announce a
> partly code freeze of our repository.
> Any comments?

The overall plan looks very, very good. I regret that I brought bad news...

Best regards,
Grzegorz Kossakowski (being very sad because of failed Algebra exam...)

View raw message