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/01/02 13:30:09 UTC
Planing Cocoon Core 2.2 M3
Daniel and Carsten have been investing a lot of time and work into splitting up
core into smaller pieces and they have also started to transform Avalon
components into POJOs. The question now is where to draw the line. When is
everything being considered stable enough (interfaces, classes being in the
right modules) to be released as release candidate and what should better go
into point releases or 3.0? Can we render a list of finite tasks?
As discussed some weeks ago, I would like to release Cocoon Core 2.2 M3 by the
end of the month and have a first release candidate in February.
Comments?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Planing Cocoon Core 2.2 M3
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
>
> Daniel and Carsten have been investing a lot of time and work into
> splitting up core into smaller pieces and they have also started to
> transform Avalon components into POJOs. The question now is where to
> draw the line. When is everything being considered stable enough
> (interfaces, classes being in the right modules) to be released as
> release candidate and what should better go into point releases or
> 3.0? Can we render a list of finite tasks?
To get the splitting of the core right will take some time, but that
should not hinder any releases as long as we make clear that people
should depend on the cocoon-core module and that the more fine grained
split that the cocoon-core in turn depend on currently is experimental
and that it is subject to change.
For the POJOfication of the components I think we should keep but
deprecate the possibility to manage sitemap components the Avalon way.
For the rest of the components I don't think that it is worthwhile to
keep the Avalon functionality. But as it will take time to convert them
all we have to live with the situation that some are converted an some
are not. But for most users that should not mater much as they will used
th predefined components anyway.
> As discussed some weeks ago, I would like to release Cocoon Core 2.2
> M3 by the end of the month and have a first release candidate in
> February.
+1
/Daniel
Re: Reducing the number of POM artifacts in trunk
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> All core modules depend on the core-modules POM now. This means that we only
> have three layers, for example:
>
> trunk/pom.xml ........................ pom artifact
> core/pom.xml ....................... pom artifact
> cocoon-xml ....................... no POM at this level anymore
> cocoon-xml-api/pom.xml ......... jar artifact
>
> The build runs through and also Continuum seems to be happy. We should do the
> same now for blocks and tools.
>
Thanks Reinhard!
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Reducing the number of POM artifacts in trunk
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> There is one question: In my opinion we have too many parent poms. The
>> configurator is a child of the core-configuration which is a child of
>> core which is a child of Cocoon which is a child of the apache root pom.
>> Is there any way to simplify this?
>
> Yes I know, that's a real PITA. One option is making
> org.apache.cocoon:cocoon-core-modules being the parent of all core
> modules and org.apache.cocoon:blocks being the parent of all blocks. (I
> don't want to reduce these two POM modules either as they are needed for
> the site generation.)
>
> But, I don't know if this can cause any problems if the logical
> hierarchy is different to the directory structure. Does anybody know? Jorg?
>
> But maybe we should just try it out ;-)
All core modules depend on the core-modules POM now. This means that we only
have three layers, for example:
trunk/pom.xml ........................ pom artifact
core/pom.xml ....................... pom artifact
cocoon-xml ....................... no POM at this level anymore
cocoon-xml-api/pom.xml ......... jar artifact
The build runs through and also Continuum seems to be happy. We should do the
same now for blocks and tools.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Reducing the number of POM artifacts in trunk
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> There is one question: In my opinion we have too many parent poms. The
> configurator is a child of the core-configuration which is a child of
> core which is a child of Cocoon which is a child of the apache root pom.
> Is there any way to simplify this?
Yes I know, that's a real PITA. One option is making
org.apache.cocoon:cocoon-core-modules being the parent of all core modules and
org.apache.cocoon:blocks being the parent of all blocks. (I don't want to reduce
these two POM modules either as they are needed for the site generation.)
But, I don't know if this can cause any problems if the logical hierarchy is
different to the directory structure. Does anybody know? Jorg?
But maybe we should just try it out ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Planing Cocoon Core 2.2 M3
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>> I want to release the spring-configurator in the middle of January
>
> What will it be labeled? I guess 1.0-RC1?
Hmm, I would like to call it 1.0 right away. If there are problems, we
can release a 1.0.1 asap. It's a small module anyway.
> At http://cocoon.zones.apache.org/daisy/cdocs-site-main/g4/g1/1199.html you
> should find everything explained for the actual release work.
Thanks for the pointer!
There is one question: In my opinion we have too many parent poms. The
configurator is a child of the core-configuration which is a child of
core which is a child of Cocoon which is a child of the apache root pom.
Is there any way to simplify this?
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planing Cocoon Core 2.2 M3
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> Daniel and Carsten have been investing a lot of time and work into splitting up
>> core into smaller pieces and they have also started to transform Avalon
>> components into POJOs. The question now is where to draw the line. When is
>> everything being considered stable enough (interfaces, classes being in the
>> right modules) to be released as release candidate and what should better go
>> into point releases or 3.0? Can we render a list of finite tasks?
>>
>> As discussed some weeks ago, I would like to release Cocoon Core 2.2 M3 by the
>> end of the month and have a first release candidate in February.
>>
>> Comments?
>>
> I want to release the spring-configurator in the middle of January
What will it be labeled? I guess 1.0-RC1?
At http://cocoon.zones.apache.org/daisy/cdocs-site-main/g4/g1/1199.html you
should find everything explained for the actual release work.
> , so
> I'm currently testing and working on the docs.
Do you need help with the Daisy setup (see the how-to section of
http://cocoon.zones.apache.org/daisy/cdocs/1201.html)? If yes, just let me know!
> Apart from that, the ongoing work of splitting up and transforming
> avalon components into Pojos will take a long time, but should/will at
> no point of time prevent us from releasing something.
ok. Then I plan for a release of M3 in about 4 weeks. It would be great if there
are no major refactorings around the release date.
> It would be great to have a final 2.2 version out before ApacheCon EU,
> so the earlier we can have a m3 the better.
seems to be feasible but after the long history of 2.2 ... ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Planing Cocoon Core 2.2 M3
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Daniel and Carsten have been investing a lot of time and work into splitting up
> core into smaller pieces and they have also started to transform Avalon
> components into POJOs. The question now is where to draw the line. When is
> everything being considered stable enough (interfaces, classes being in the
> right modules) to be released as release candidate and what should better go
> into point releases or 3.0? Can we render a list of finite tasks?
>
> As discussed some weeks ago, I would like to release Cocoon Core 2.2 M3 by the
> end of the month and have a first release candidate in February.
>
> Comments?
>
I want to release the spring-configurator in the middle of January, so
I'm currently testing and working on the docs.
Apart from that, the ongoing work of splitting up and transforming
avalon components into Pojos will take a long time, but should/will at
no point of time prevent us from releasing something.
It would be great to have a final 2.2 version out before ApacheCon EU,
so the earlier we can have a m3 the better.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/