Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (nike.apache.org: domain of grek@tuffmail.com designates
 216.86.168.178 as permitted sender)
Message-ID: <47D06112.4010702@tuffmail.com>
Date: Thu, 06 Mar 2008 22:24:34 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20070801)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Releasing Cocoon 2.2, finally!
References: <47CFF88A.8060001@apache.org>
In-Reply-To: <47CFF88A.8060001@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 I
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 if
cocoon-servlet-service-impl is used outside the Cocoon there is no default implementation of
SourceResolver registered as a Spring bean. It's not a big deal, because Excalibur provides such
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 first
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 across
some NPEs for specific servlet bean configurations and I haven't had enough free time to dig into
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 Cocoon.
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 of
cocoon-servlet-service-impl. If I come up with the fix until Monday, do you think it's a good idea
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...)