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...)
