You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/09/05 08:36:25 UTC
Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Let's move this into a different thread :)
Daniel Fagerstrom wrote:
>>
>>I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
>>the GetTogether.
>
>
> +1
>
> When the OSGi stuff are changed to R4 and is usefull enough we can start
> to include it within 2.2.x releases for early adaptors. And when it is
> stable enough and we have all infrastructure in terms of block
> repositories, deploy tools, build system etc in place, we can remove the
> "classic" way and release a 3.0.
>
Ok, this sound reasonable. I see currently two major things that have to
be done for releasing a version of 2.2:
a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not
in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if
everyone syncs between one and four blocks, we can get over this very
quickly.
b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested.
If these things are fixed, +1 for 2.2M1 after the GT.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler wrote:
>Carsten Ziegeler wrote:
>
>
>>Let's move this into a different thread :)
>>
>>Daniel Fagerstrom wrote:
>>
>>
>>
>>>>I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
>>>>the GetTogether.
>>>>
>>>>
>>>+1
>>>
>>>When the OSGi stuff are changed to R4 and is usefull enough we can start
>>>to include it within 2.2.x releases for early adaptors. And when it is
>>>stable enough and we have all infrastructure in terms of block
>>>repositories, deploy tools, build system etc in place, we can remove the
>>>"classic" way and release a 3.0.
>>>
>>>
>>>
>>Ok, this sound reasonable. I see currently two major things that have to
>>be done for releasing a version of 2.2:
>>
>>a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not
>>in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if
>>everyone syncs between one and four blocks, we can get over this very
>>quickly.
>>b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested.
>>
>>If these things are fixed, +1 for 2.2M1 after the GT.
>>
>>Carsten
>>
>>
>>
>And releasing 2.2 would mean that *NO NEW FEATURES GO TO 2.1.x* from
>this point on :)
>
>
+1
/me need to move to 2.2 quickly! :-)
Best Regards,
Antonio Gallardo
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> Let's move this into a different thread :)
>
> Daniel Fagerstrom wrote:
>
>>>I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
>>>the GetTogether.
>>
>>
>>+1
>>
>>When the OSGi stuff are changed to R4 and is usefull enough we can start
>>to include it within 2.2.x releases for early adaptors. And when it is
>>stable enough and we have all infrastructure in terms of block
>>repositories, deploy tools, build system etc in place, we can remove the
>>"classic" way and release a 3.0.
>>
>
> Ok, this sound reasonable. I see currently two major things that have to
> be done for releasing a version of 2.2:
>
> a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not
> in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if
> everyone syncs between one and four blocks, we can get over this very
> quickly.
> b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested.
>
> If these things are fixed, +1 for 2.2M1 after the GT.
>
> Carsten
>
And releasing 2.2 would mean that *NO NEW FEATURES GO TO 2.1.x* from
this point on :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 05 September 2005 23:52, Upayavira wrote:
> In R4 (or rather in Oscar 2.0Alpha) you can specify exports such as
> o.a.c.transformation.*Generator. This would be enough for us to avoid
> having to rename packages. However, it would likely lead to some complex
> wildcard expressions, so I would propose that we ignore that
> functionality and use unique package names per block, as per R3.
There is also the concern of "sealed" Jars of the JVM that should be taken
into consideration. IMHO, separation is a GoodThing and should be carried out
instead of hanging on to bad habits.
Cheers
Niclas
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Upayavira <uv...@odoko.co.uk>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler wrote:
>
>> Ralph Goers wrote:
>>
>>
>>>> How much do we know about the directory structure required by Maven?
>>>> I know that OSGi R3 requires a directory structure, R4 doesn't.
>>>>
> Don't understand the comment (from Upayavira) about directory structure,
> R3 and R4, care to explain?
In R4 (or rather in Oscar 2.0Alpha) you can specify exports such as
o.a.c.transformation.*Generator. This would be enough for us to avoid
having to rename packages. However, it would likely lead to some complex
wildcard expressions, so I would propose that we ignore that
functionality and use unique package names per block, as per R3.
<snip/>
Upayavira
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> At least for OSGi R3, each block (bundle) must export a unique set of
> packages. It would be nice if we could move all classes and interfaces
> so this is the case and deprecate the block classes and interface with
> non unique packages before we release 2.2.0 final. It is not particulary
> complicated but requires some work.
>
> It is necessary (if it hasn't changed in R4), that we move to block
> unique package names before we start to release OSGi functionality. So
> the sooner we can deprecate the non unique package use, the better. But
> it is not a blocker for 2.2.
>
I think someone mentioned that R4 does not require the unique package
names anymore. hmm, but I'm not sure.
> It is not necessary to split into api and implementation for introducing
> OSGi, but it will certainly be easier to use, and scale much better if
> we do it. Especially when there are several blocks implementing the same
> api, it will simplify things if we have separate api blocks. Then the
> api blocks that a block depends on can be downloaded during compilation
> of the block, and the user can choose between several implementaions of
> the used apis while deployoing the block.
>
Yepp.
> Spliting the code into api and implemetation require however
> considerable work and thought as not everything is designed with such a
> split in mind. So I think that is something that we need to work on
> incrementally.
>
Agreed.
> --- o0o ---
>
> Considering what we need to _change_ to get real blocks: The only thing
> I know about is some package renaming as discussed above. It will be
> more about _adding_ things. We will need manifest files with OSGi info
> in and we will need block.xml that describe dependencies on other blocks
> and bundles (this need to be integrated with the m2 dependecy
> information). The block.xml will also contain references to the blocks
> (sample) sitemap and component configuration(s) as we discussed last
> weak. This is all things that we can work on in an evolutionary way.
>
> From my current knowledge the largest remaining question is about how
> to configure components that a block exposes. Part of it is clear, the
> block.xml can refer to the .xconf(s) that is part of the block today and
> export the components within the configuration so that it is available
> to other blocks (through OSGi services as discussed earlier). This far
> everything is as before, but done using OSGi instead of using compile
> time mechanism.
>
> The question is how a user should be able to adapt the configuration of
> the components of the block while using it. Today one can modify the
> component configuration snippets by hand, but that is not as easy while
> using blocks as the configuration will be embeded in a precompiled block
> that is packaged as a bundle and asumed to be used as is. One possible
> solution is to decide before hand what should be deploy time
> configurable and use block attributes for this (BTW block attributes and
> the setting stuff that Carsten and Ralph are discussing seem to have a
> lot in common, we should see if the block attributes could be build
> avbove or integrated with the settings stuff). Another solution is to
> export the implementation of the components and configure them in the
> block that uses them instead (don't like this though, as it don't give
> any isolation). A third solution could maybe be to declare the
> configuration as a "fragment" that can be overided. Fragments is an
> Eclipse concept that have been made part of OSGi R4, I don't know enough
> about it to say if it is usefull in this context. Other ideas?
>
I think one of the main problems is that you never know what
configuration a component uses/requires. So I think we need a formal
description for each configurable component, like a schema or something.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
>Ralph Goers wrote:
>
>
>>>How much do we know about the directory structure required by Maven? I
>>>know that OSGi R3 requires a directory structure, R4 doesn't.
>>>
Don't understand the comment (from Upayavira) about directory structure,
R3 and R4, care to explain?
>>>However,
>>>one package per bundle would make implementation much easier.
>>>
>>>
At least for OSGi R3, each block (bundle) must export a unique set of
packages. It would be nice if we could move all classes and interfaces
so this is the case and deprecate the block classes and interface with
non unique packages before we release 2.2.0 final. It is not particulary
complicated but requires some work.
It is necessary (if it hasn't changed in R4), that we move to block
unique package names before we start to release OSGi functionality. So
the sooner we can deprecate the non unique package use, the better. But
it is not a blocker for 2.2.
>>Unfortunately, my knowledge only extends to Maven 1. Carsten would have
>>to answer this as he has been working on the conversion to Maven 2. It
>>doesn't look like he has had to do much so far, but I'm still worried
>>that circular dependencies between blocks are going to show up.
>>
>>
>Currently we don't have circular dependencies, so the current structure
>will work with maven as well. Now m1 and m2 do not differ that much when
>it comes to the directory structure: one java source directory per
>project, several resource directories (if you need), on directory for
>java tests etc. So this works pretty well for our current blocks.
>If we want to split blocks into api and impl for example, we have to
>create two maven projects - this of course then will also reduce
>problems with circular dependencies.
>I don't know if we need something else for osgi, but I think this
>approach (api vs impl) should work there as well.
>
>
It is not necessary to split into api and implementation for introducing
OSGi, but it will certainly be easier to use, and scale much better if
we do it. Especially when there are several blocks implementing the same
api, it will simplify things if we have separate api blocks. Then the
api blocks that a block depends on can be downloaded during compilation
of the block, and the user can choose between several implementaions of
the used apis while deployoing the block.
Spliting the code into api and implemetation require however
considerable work and thought as not everything is designed with such a
split in mind. So I think that is something that we need to work on
incrementally.
>>>I just want to avoid any "we can't release X because we're waiting for
>>>feature Y", that is something we've stumbled with all too often.
>>>
>>>
+1
We should get into the habit of releasing what we actually have done
rather, than not releasing because we developed something else than what
we planned.
>>Yes, I would like to avoid that as well. However, I don't know that we
>>need to be using a formally released Maven 2 to know how to do this.
>>
>>
>>
>I think time will tell. Switching to maven is currently at a very low
>rate, not many of us are working on it (which is ok of course), the same
>happens to the OSGi stuff. We shouldn't delay 2.2 neither because of
>waiting for m2 nor waiting for OSGi. The current version seems to work
>and build system works as well.
>
>
Exactly.
--- o0o ---
Considering what we need to _change_ to get real blocks: The only thing
I know about is some package renaming as discussed above. It will be
more about _adding_ things. We will need manifest files with OSGi info
in and we will need block.xml that describe dependencies on other blocks
and bundles (this need to be integrated with the m2 dependecy
information). The block.xml will also contain references to the blocks
(sample) sitemap and component configuration(s) as we discussed last
weak. This is all things that we can work on in an evolutionary way.
From my current knowledge the largest remaining question is about how
to configure components that a block exposes. Part of it is clear, the
block.xml can refer to the .xconf(s) that is part of the block today and
export the components within the configuration so that it is available
to other blocks (through OSGi services as discussed earlier). This far
everything is as before, but done using OSGi instead of using compile
time mechanism.
The question is how a user should be able to adapt the configuration of
the components of the block while using it. Today one can modify the
component configuration snippets by hand, but that is not as easy while
using blocks as the configuration will be embeded in a precompiled block
that is packaged as a bundle and asumed to be used as is. One possible
solution is to decide before hand what should be deploy time
configurable and use block attributes for this (BTW block attributes and
the setting stuff that Carsten and Ralph are discussing seem to have a
lot in common, we should see if the block attributes could be build
avbove or integrated with the settings stuff). Another solution is to
export the implementation of the components and configure them in the
block that uses them instead (don't like this though, as it don't give
any isolation). A third solution could maybe be to declare the
configuration as a "fragment" that can be overided. Fragments is an
Eclipse concept that have been made part of OSGi R4, I don't know enough
about it to say if it is usefull in this context. Other ideas?
/Daniel
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>
>>How much do we know about the directory structure required by Maven? I
>>know that OSGi R3 requires a directory structure, R4 doesn't. However,
>>one package per bundle would make implementation much easier.
>
>
> Unfortunately, my knowledge only extends to Maven 1. Carsten would have
> to answer this as he has been working on the conversion to Maven 2. It
> doesn't look like he has had to do much so far, but I'm still worried
> that circular dependencies between blocks are going to show up.
>
Currently we don't have circular dependencies, so the current structure
will work with maven as well. Now m1 and m2 do not differ that much when
it comes to the directory structure: one java source directory per
project, several resource directories (if you need), on directory for
java tests etc. So this works pretty well for our current blocks.
If we want to split blocks into api and impl for example, we have to
create two maven projects - this of course then will also reduce
problems with circular dependencies.
I don't know if we need something else for osgi, but I think this
approach (api vs impl) should work there as well.
>
>>I just want to avoid any "we can't release X because we're waiting for
>>feature Y", that is something we've stumbled with all too often.
>
>
> Yes, I would like to avoid that as well. However, I don't know that we
> need to be using a formally released Maven 2 to know how to do this.
>
I think time will tell. Switching to maven is currently at a very low
rate, not many of us are working on it (which is ok of course), the same
happens to the OSGi stuff. We shouldn't delay 2.2 neither because of
waiting for m2 nor waiting for OSGi. The current version seems to work
and build system works as well.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Ralph Goers <Ra...@dslextreme.com>.
Upayavira wrote:
>
> How much do we know about the directory structure required by Maven? I
> know that OSGi R3 requires a directory structure, R4 doesn't. However,
> one package per bundle would make implementation much easier.
Unfortunately, my knowledge only extends to Maven 1. Carsten would have
to answer this as he has been working on the conversion to Maven 2. It
doesn't look like he has had to do much so far, but I'm still worried
that circular dependencies between blocks are going to show up.
>
> I just want to avoid any "we can't release X because we're waiting for
> feature Y", that is something we've stumbled with all too often.
Yes, I would like to avoid that as well. However, I don't know that we
need to be using a formally released Maven 2 to know how to do this.
Ralph
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Upayavira <uv...@odoko.co.uk>.
Ralph Goers wrote:
>
>
> Upayavira wrote:
>
>> Ralph Goers wrote:
>>
>>>
>>> Where does the switch to Maven 2 fit into this picture?
>>
>>
>>
>> Probably 2.2M2 or 2.2M3, depending on how quick people are in
>> implementing it!
>
> I'm not sure whether "people" means the maven developers or us. I bring
> this up because 1) maven 2 isn't released yet and 2) as I stated earlier
> it could have an impact on the directory structure that Cocoon uses.
> Doing that after 2.2.0 goes out could be a problem (but obviously
> wouldn't be if it is done in a milestone release). I'd also be
> concerned if converting blocks to be compatible with OSGi in 2.2 would
> introduce the same problem. Hopefully, enough research has already been
> done that this can be handled before 2.2.0 is released.
How much do we know about the directory structure required by Maven? I
know that OSGi R3 requires a directory structure, R4 doesn't. However,
one package per bundle would make implementation much easier.
I just want to avoid any "we can't release X because we're waiting for
feature Y", that is something we've stumbled with all too often.
Regards,
Upayavira
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Ralph Goers <Ra...@dslextreme.com>.
Upayavira wrote:
> Ralph Goers wrote:
>
>>
>> Where does the switch to Maven 2 fit into this picture?
>
>
> Probably 2.2M2 or 2.2M3, depending on how quick people are in
> implementing it!
>
> Regards, Upayavira
I'm not sure whether "people" means the maven developers or us. I bring
this up because 1) maven 2 isn't released yet and 2) as I stated earlier
it could have an impact on the directory structure that Cocoon uses.
Doing that after 2.2.0 goes out could be a problem (but obviously
wouldn't be if it is done in a milestone release). I'd also be
concerned if converting blocks to be compatible with OSGi in 2.2 would
introduce the same problem. Hopefully, enough research has already been
done that this can be handled before 2.2.0 is released.
Ralph
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Upayavira <uv...@odoko.co.uk>.
Ralph Goers wrote:
>
>
> Carsten Ziegeler wrote:
>
>> Let's move this into a different thread :)
>>
>> Daniel Fagerstrom wrote:
>>
>>
>>>> I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
>>>> the GetTogether.
>>>>
>>>
>>> +1
>>>
>>> When the OSGi stuff are changed to R4 and is usefull enough we can start
>>> to include it within 2.2.x releases for early adaptors. And when it is
>>> stable enough and we have all infrastructure in terms of block
>>> repositories, deploy tools, build system etc in place, we can remove the
>>> "classic" way and release a 3.0.
>>>
>>>
>>
>> Ok, this sound reasonable. I see currently two major things that have to
>> be done for releasing a version of 2.2:
>>
>> a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not
>> in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if
>> everyone syncs between one and four blocks, we can get over this very
>> quickly.
>> b) Adjust the build scripts to exclude the osgi stuff as Daniel
>> suggested.
>>
>> If these things are fixed, +1 for 2.2M1 after the GT.
>>
>> Carsten
>>
>>
>>
> Where does the switch to Maven 2 fit into this picture?
Probably 2.2M2 or 2.2M3, depending on how quick people are in
implementing it!
Regards, Upayavira
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for
components?]
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>Let's move this into a different thread :)
>
>Daniel Fagerstrom wrote:
>
>
>>>I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after
>>>the GetTogether.
>>>
>>>
>>+1
>>
>>When the OSGi stuff are changed to R4 and is usefull enough we can start
>>to include it within 2.2.x releases for early adaptors. And when it is
>>stable enough and we have all infrastructure in terms of block
>>repositories, deploy tools, build system etc in place, we can remove the
>>"classic" way and release a 3.0.
>>
>>
>>
>Ok, this sound reasonable. I see currently two major things that have to
>be done for releasing a version of 2.2:
>
>a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not
>in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if
>everyone syncs between one and four blocks, we can get over this very
>quickly.
>b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested.
>
>If these things are fixed, +1 for 2.2M1 after the GT.
>
>Carsten
>
>
>
Where does the switch to Maven 2 fit into this picture?
Ralph