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, SN 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?]
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, SN 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?]
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?]
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
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
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?]
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
Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
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, SN 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?]
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?]
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
