You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/11/21 17:05:32 UTC
Upgrade to Spring 2.5
Since I've been running successfully two of my custom Cocoon 2.2 apps with
Spring 2.5-rc2
(http://opensource.atlassian.com/projects/spring/browse/SPR-4081), I upgraded
trunk to use Spring 2.5. Since it is aimed to be a drop-in replacement for
2.0.x, I don't expect problems. Doing the upgrade now gives us some time until
we release Cocoon 2.2 final which is scheduled for the end of the year.
Now we can also think about merging Daniel's work on OSGi (whiteboard), which
requires Spring-OSGi, with trunk. Daniel, maybe you can share your thoughts on
what this would mean for trunk (build system, required code changes, etc.) and
how we can keep the experimental OSGi stuff out of our releases.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: Upgrade to Spring 2.5
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> Since I've been running successfully two of my custom Cocoon 2.2 apps
>> with Spring 2.5-rc2
>> (http://opensource.atlassian.com/projects/spring/browse/SPR-4081), I
>> upgraded trunk to use Spring 2.5. Since it is aimed to be a drop-in
>> replacement for 2.0.x, I don't expect problems. Doing the upgrade now
>> gives us some time until we release Cocoon 2.2 final which is scheduled
>> for the end of the year.
>>
>> Now we can also think about merging Daniel's work on OSGi (whiteboard),
>> which requires Spring-OSGi, with trunk. Daniel, maybe you can share your
>> thoughts on what this would mean for trunk (build system, required code
>> changes, etc.) and how we can keep the experimental OSGi stuff out of
>> our releases.
>>
> I really like Daniels stuff but why merging it now? Can't we just wait
> after the final release?
I don't think that there is much difference if we add it between 2.2.0-rc2 and
2.2.0-final or 2.2.0 and 2.2.1. AFAIU it's only a different way to build and
package Cocoon.
But I agree with you and Grek that we should wait with the merge because we
should focus our limited resources on the final release instead of getting
side-tracked.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: Upgrade to Spring 2.5
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> Reinhard Poetz wrote:
> I really like Daniels stuff but why merging it now? Can't we just wait
> after the final release?
+1
Since we want to release 2.2 before Christmas I think it's too late for such big changes.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Upgrade to Spring 2.5
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> Since I've been running successfully two of my custom Cocoon 2.2 apps
> with Spring 2.5-rc2
> (http://opensource.atlassian.com/projects/spring/browse/SPR-4081), I
> upgraded trunk to use Spring 2.5. Since it is aimed to be a drop-in
> replacement for 2.0.x, I don't expect problems. Doing the upgrade now
> gives us some time until we release Cocoon 2.2 final which is scheduled
> for the end of the year.
>
> Now we can also think about merging Daniel's work on OSGi (whiteboard),
> which requires Spring-OSGi, with trunk. Daniel, maybe you can share your
> thoughts on what this would mean for trunk (build system, required code
> changes, etc.) and how we can keep the experimental OSGi stuff out of
> our releases.
>
I really like Daniels stuff but why merging it now? Can't we just wait
after the final release?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Upgrade to Spring 2.5
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
>> Now we can also think about merging Daniel's work on OSGi
>> (whiteboard), which requires Spring-OSGi, with trunk. Daniel, maybe
>> you can share your thoughts on what this would mean for trunk (build
>> system, required code changes, etc.) and how we can keep the
>> experimental OSGi stuff out of our releases.
>
> I have not worked on it for a while so I don't remember all details. But
> the main part is making the cocoon jars bundles. This is preferably done
> with the Felix maven-bundle-plugin. I've written poms that contain the
> configuration of that plugin for all core blocks. The poms can be found
> here http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/.
<snip/>
Thanks Daniel! I hope to find some time in December to have a closer look on
what needs to be done.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: Upgrade to Spring 2.5
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
>
> Since I've been running successfully two of my custom Cocoon 2.2 apps
> with Spring 2.5-rc2
> (http://opensource.atlassian.com/projects/spring/browse/SPR-4081), I
> upgraded trunk to use Spring 2.5. Since it is aimed to be a drop-in
> replacement for 2.0.x, I don't expect problems. Doing the upgrade now
> gives us some time until we release Cocoon 2.2 final which is scheduled
> for the end of the year.
Great!
> Now we can also think about merging Daniel's work on OSGi (whiteboard),
> which requires Spring-OSGi, with trunk. Daniel, maybe you can share your
> thoughts on what this would mean for trunk (build system, required code
> changes, etc.) and how we can keep the experimental OSGi stuff out of
> our releases.
I have not worked on it for a while so I don't remember all details. But
the main part is making the cocoon jars bundles. This is preferably done
with the Felix maven-bundle-plugin. I've written poms that contain the
configuration of that plugin for all core blocks. The poms can be found
here http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/.
Using the Felix maven-bundle-plugin will add OSGi manifest.mf and will
not disturb non OSGi usage the slightest. So this can be done right away.
Second there are a number of spring-osgi configuration files that are
placed in the META-INF/spring directories of the bundles. This directory
isn't used in standard Cocoon, so these configuration files could also
be added to trunk without cusing any problems.
For the Java code I add a package to the cocoon-servlet-service-impl
that depends on the OSGi framework and some services. If we don't want
such dependencies in trunk we could either add a special block for that
package or have some compilation profile. There is also some code that
is spring-osgi specific in
http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/cocoon-spring-osgi/.
I have tried to make the spring-osgi project interested in spring-osgi,
but that seem to have low priority right now for them.
The main thing that I don't know how to solve is dependencies on
bundelized versions of common libraries. I replace all the ordinary
block dependencies with dependencies on bundelized versions of the
libraries. By doing that I can use the Maven assembly plugin for
collecting and installing all the needed bundle dependencies for the
Cocoon block, so that it is easy to execute cocoon-osg, see
http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/cocoon-osgi-main/.
It would in most cases be possible to used the bundelized versions of
the libraries for standard Cocoon as well. But the problem is that the
bundelized jars in most cases not are released.
The bundelized Cocoon jars can be compiled with the standard
dependencies in trunk. But in that case one have to depend explicitely
on the bundelized version when creating thee cocoon-osgi assembly. This
is rather inconvenient, but I don't see any other option if we want to
move the OSGi stuff to trunk. Maybe one can do some clever thing with
Maven profiles.
/Daniel