Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: I don't think so. I really don't want to have two files with system properties in them. As I said, we have an XML file that contains iniital logging configuration along with system properties. We use this same file (well, the contents might be different) in different applications, many of which are not Cocoon based. So I really don't want to tell folks that in application A, B and C you add logging definitions and properties to the XML file but in applications D and E you put only the logging defintions in the XML file and properties go in a property file. Ah, I think now I get it (sorry, early in the morning I sometimes need to wakeup): The plugin component we are talking about will in your case read the XML and extract the properties from the XML file and deliver it to the Cocoon core while the rest of the file is used somewhere else, right? Ok, I think we can control this by...tata...properties...I think we can do something like a org.apache.cocoon.properties.controller=YOURCLASS|ANOTHERCLASS and this class has some interface and delivers the properties. How does this sound? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Ah, I think now I get it (sorry, early in the morning I sometimes need to wakeup): You're right. It is very early in the morning - a quarter to 1am to be exact. About time for bed since I have to be up at 5:30am. The plugin component we are talking about will in your case read the XML and extract the properties from the XML file and deliver it to the Cocoon core while the rest of the file is used somewhere else, right? This is correct. Ok, I think we can control this by...tata...properties...I think we can do something like a org.apache.cocoon.properties.controller=YOURCLASS|ANOTHERCLASS and this class has some interface and delivers the properties. How does this sound? This sounds just fine to me. Ralph
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Ok a first version is there which is a base to continue the discussion - for some reason I don't know I named it PropertyProvider which is a simple interface with just one method. If such a property is set, an instance of the class is created and invoked. Now I can imagine, that you might need more, like getting a SourceResolver or something like that? Carsten Would I even be able to get a source resolver? You haven't read cocoon.xconf yet. Our code uses a modified version of the the Avalon configuration stuff so I use that to read my XML file, so for me I probably won't need any more than what you've probably done. Since the system is in a pretty primitive state when you are doing this I doubt much more can be done. Ralph
Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: Would I even be able to get a source resolver? You haven't read cocoon.xconf yet. Yes :) Cocoon itself uses a simple bootstrap source resolver which is able to do relative resolving and supports the context and resource protocol. So, we could pass this to your component. Our code uses a modified version of the the Avalon configuration stuff so I use that to read my XML file, so for me I probably won't need any more than what you've probably done. Since the system is in a pretty primitive state when you are doing this I doubt much more can be done. Yepp, that's true - now, if you don't need the source resolver I think we will leave it the way it is (we can add everything later on); if you need it, I would add the support for Serviceable where you get a simple service manager managing just the source resolver mentioned above. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Ralph Goers wrote: Would I even be able to get a source resolver? You haven't read cocoon.xconf yet. Yes :) Cocoon itself uses a simple bootstrap source resolver which is able to do relative resolving and supports the context and resource protocol. So, we could pass this to your component. Our code uses a modified version of the the Avalon configuration stuff so I use that to read my XML file, so for me I probably won't need any more than what you've probably done. Since the system is in a pretty primitive state when you are doing this I doubt much more can be done. Yepp, that's true - now, if you don't need the source resolver I think we will leave it the way it is (we can add everything later on); if you need it, I would add the support for Serviceable where you get a simple service manager managing just the source resolver mentioned above. Carsten OK. Ralph
Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: First, I'm assuming this is the code you spoke of a while ago to move values outside of Cocoon.xconf and the sitemap so that things like database ports, etc can be defined outside the webapp? Yepp. Well, basically I would need to be able to do whatever you are doing while getting the data from a different file. We have an XML file that has some initial logging configuration as well as a section for system property settings. I'd like to add whatever data you are reading to that file so that the server only needs one configuration file outside the webapp. Basically, I would provide the routine to read the data from wherever I want and your routine would process it. Ok, the current solution is property based (name - value pairs). If we would make this pluggable, would this work for you? For example, we could convert an XML file into properties. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Sylvain Wallez wrote: Wow. That would actually be a lot of backporting IMO, meaning the 2.1 branch wouldn't be very different from the trunk! This feature alone will make people jump to 2.2 once we release it, even as a beta. So I agree with Upayavira: let's release a 2.2 without OSGi and concentrate on it for 2.3. And BTW, instrumentable is currently broken (I suspect some binary incompatibility between Excalibur libraries). Excalibur has released a new version of most libraries recently. We should upgrade. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
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: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Ok, the current solution is property based (name - value pairs). If we would make this pluggable, would this work for you? For example, we could convert an XML file into properties. Carsten I think making it pluggable is what I requested in the first place. But I wouldn't want ot assume that an XML file has nothing else in it other than properties. So I would prefer that the plug-in have the responsibility of interpreting whatever datasource it is reading. Ralph
Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: Carsten Ziegeler wrote: Ok, the current solution is property based (name - value pairs). If we would make this pluggable, would this work for you? For example, we could convert an XML file into properties. Carsten I think making it pluggable is what I requested in the first place. But I wouldn't want ot assume that an XML file has nothing else in it other than properties. So I would prefer that the plug-in have the responsibility of interpreting whatever datasource it is reading. Ok, I understand this of course, the question is, how do you want to get the information? Currently you can get all properties read from Cocoon in your own component/code. If we make the reading pluggable, we also need a way to deliver this information to the components that are interested in it. 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: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Ok, I understand this of course, the question is, how do you want to get the information? Currently you can get all properties read from Cocoon in your own component/code. If we make the reading pluggable, we also need a way to deliver this information to the components that are interested in it. Carsten What does your code currently do? I thought it replaced variables in cocoon.xconf. I guess I was assuming that it would continue to do that. 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
Re: [2.2] Using includes in the sitemap for components?
Daniel Fagerstrom wrote: So, let us stop the branching madness and work towards having only *one* common branch (the trunk), that we do the releases from. +1 Best Regards, Antonio Gallardo
Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: Currently, all the code that needs access to that file goes through a single component. That component uses a system property to specify where the file is. But in this case, you can dream up pretty much anything that works. I'm presuming that putting them in cocoon.xconf is out since that is what is being modified. Yes. I hate putting them in web.xml but is OK if that is the only way. Another way that works for me is for your factory to have methods that I can invoke from Spring's lifecycle config. My logging implementation causes Spring to initialize when logging is set up. Propose something else if you hate all of these. Hmm, you can put your own properties file into WEB-INF/properties directory. All these properties are available using the Settings object. You can inject the Cocoon core object into one of your Spring components, access the settings object from there and get your properties. Isn't it this, what you need? (If yes, it works today :) ) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Hmm, you can put your own properties file into WEB-INF/properties directory. All these properties are available using the Settings object. You can inject the Cocoon core object into one of your Spring components, access the settings object from there and get your properties. Isn't it this, what you need? (If yes, it works today :) ) I don't think so. I really don't want to have two files with system properties in them. As I said, we have an XML file that contains iniital logging configuration along with system properties. We use this same file (well, the contents might be different) in different applications, many of which are not Cocoon based. So I really don't want to tell folks that in application A, B and C you add logging definitions and properties to the XML file but in applications D and E you put only the logging defintions in the XML file and properties go in a property file. Ralph
Re: [2.2] Using includes in the sitemap for components?
Niclas Hedhman wrote: On Sunday 04 September 2005 23:10, Carsten Ziegeler wrote: Hmm, for a) I more and more think we should move the whole ECM++ stuff from 2.2 to 2.1.x (readd the support for Composable and Instrumentable) and be able to use all the nice little things from 2.2 *today* That sounds more like it is time for 2.1.x to become 2.2 and the HEAD targets a 2.3, or even a 3.0, with real-blocks. I guess I'd have to agree. It would probably be easier to do this way and it would give our customers a clue that something changed. Ralph
Re: [2.2] Using includes in the sitemap for components?
Niclas Hedhman wrote: On Sunday 04 September 2005 23:10, Carsten Ziegeler wrote: Hmm, for a) I more and more think we should move the whole ECM++ stuff from 2.2 to 2.1.x (readd the support for Composable and Instrumentable) and be able to use all the nice little things from 2.2 *today* That sounds more like it is time for 2.1.x to become 2.2 and the HEAD targets a 2.3, or even a 3.0, with real-blocks. Dewey to me has always meant that a new feature increases the second digit, but the 2.1.x line have seen all kinds of new features being added. What's the scare to use up more numbers?? I couldn't agree more. Personally I'd be -1 on porting ECM++ back to 2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can focus on getting 2.2 out in some form, we risk some serious geopardy for our community, I think. So, let's release 2.2, make that the main branch, and start adding OSGi, Maven, etc, into 2.3. With Carsten's proposal to release every two months, we're almost back into release early, release often, but, problem is, we'd be releasing a branch often, which is seriously broken, IMO. I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after the GetTogether. Regards, Upayavira
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Ralph Goers wrote: I haven't looked at the code for this, but a) I'd love it in 2.1 and b) is it pluggable? We already have an XML file with some configuration in it including some system properties that need to be set. It would be nice if I could leverage the same file for this. Hmm, for a) I more and more think we should move the whole ECM++ stuff from 2.2 to 2.1.x (readd the support for Composable and Instrumentable) and be able to use all the nice little things from 2.2 *today* - this requires some changes in some internal classes of Cocoon but this shouldn't effect users... For b) it's not pluggable (yet). What exactly do you need? First, I'm assuming this is the code you spoke of a while ago to move values outside of Cocoon.xconf and the sitemap so that things like database ports, etc can be defined outside the webapp? Well, basically I would need to be able to do whatever you are doing while getting the data from a different file. We have an XML file that has some initial logging configuration as well as a section for system property settings. I'd like to add whatever data you are reading to that file so that the server only needs one configuration file outside the webapp. Basically, I would provide the routine to read the data from wherever I want and your routine would process it. Carsten
Re: [2.2] Using includes in the sitemap for components?
Upayavira wrote: I couldn't agree more. Personally I'd be -1 on porting ECM++ back to 2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can focus on getting 2.2 out in some form, we risk some serious geopardy for our community, I think. So, let's release 2.2, make that the main branch, and start adding OSGi, Maven, etc, into 2.3. \ I really think we should get into the mindset that the branch with real blocks and OSGi will be 3.0. With Carsten's proposal to release every two months, we're almost back into release early, release often, but, problem is, we'd be releasing a branch often, which is seriously broken, IMO. I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after the GetTogether. +1 - If Carsten (or whomever) can move ECM++ by then. Regards, Upayavira Ralph
Re: [2.2] Using includes in the sitemap for components?
Ralph Goers wrote: Upayavira wrote: I couldn't agree more. Personally I'd be -1 on porting ECM++ back to 2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can focus on getting 2.2 out in some form, we risk some serious geopardy for our community, I think. So, let's release 2.2, make that the main branch, and start adding OSGi, Maven, etc, into 2.3. \ I really think we should get into the mindset that the branch with real blocks and OSGi will be 3.0. With Carsten's proposal to release every two months, we're almost back into release early, release often, but, problem is, we'd be releasing a branch often, which is seriously broken, IMO. I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after the GetTogether. +1 - If Carsten (or whomever) can move ECM++ by then. Huh? Nono, we shouldn't move ECM++. We should release 2.2M1 with ECM++, and 2.1.x should start its death/deprecation process soon, releasing 2,1.8 which hopefully will be the last in that branch. Regards, Upayavira
Re: [2.2] Using includes in the sitemap for components?
Upayavira wrote: ... I couldn't agree more. Personally I'd be -1 on porting ECM++ back to 2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can focus on getting 2.2 out in some form, we risk some serious geopardy for our community, I think. +1 So, let's release 2.2, make that the main branch, +1 and start adding OSGi, Maven, etc, into 2.3. -1 IMO, branching haven't done much god for our community this far, so I can't see why we should repeat our previous mistakes. OSGi and block development has this far been done in parallell with the classic Cocoon development. AFAIK it hasn't disturbed anything else in trunk this far and I don't think it will in the near future either. It might happen, (although I doubt it), that we need a branch during some part of the blocks development. If that happens, we can create a branch then. But in that case we should have a really good plan about how to make that branch short lived and possible to merge back in trunk within a very limited time span. Just creating a 2.3 or 3.0 branch because we feel that we might need it and as we have made it before would IMO be a completely unnecessary waste of community resources. Now, due to license issues we cannot release any OSGi dependent code until we have updated to OSGi R4, but that only means that we need to make sure that classic Cocoon not depend on OSGi APIs and that we exclude the OSGi stuff from the releases. This is probably a good thing to do anyway, and very little work comparing to keep two branches synchronized. With Carsten's proposal to release every two months, we're almost back into release early, release often, but, problem is, we'd be releasing a branch often, which is seriously broken, IMO. 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. --- o0o --- Remember, open source code becomes stable when many people use it. Creating development branches destabilizes the code as much fewer, if any people, use it. And after having destabilized it, it takes much resources and time to get it releasable again, and at the same time we have to support the old stable release. All this is a frustrating and a huge waste of resources, with no particular gain. So, let us stop the branching madness and work towards having only *one* common branch (the trunk), that we do the releases from. /Daniel
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote:
Ralph Goers wrote:
I haven't looked at the code for this, but a) I'd love it in 2.1 and b)
is it pluggable? We already have an XML file with some configuration in
it including some system properties that need to be set. It would be
nice if I could leverage the same file for this.
Hmm, for a) I more and more think we should move the whole ECM++ stuff
from 2.2
to 2.1.x (readd the support for Composable and Instrumentable) and be
able to use
all the nice little things from 2.2 *today* - this requires some changes
in some internal classes of Cocoon but this shouldn't effect users...
this doesn't make sense to me. Why don't we release Cocoon trunk as Cocoon 2.2
and don't continue the 2.1.* series? Then we could stop to maintain two
branches which is a PITA IMO.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [2.2] Using includes in the sitemap for components?
Upayavira wrote:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
I couldn't agree more. Personally I'd be -1 on porting ECM++ back to
2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can
focus on getting 2.2 out in some form, we risk some serious geopardy
for our community, I think.
+1
So, let's release 2.2, make that the main branch,
+1
and start adding OSGi, Maven, etc, into 2.3.
-1
IMO, branching haven't done much god for our community this far, so I
can't see why we should repeat our previous mistakes.
OSGi and block development has this far been done in parallell with
the classic Cocoon development. AFAIK it hasn't disturbed anything
else in trunk this far and I don't think it will in the near future
either.
It might happen, (although I doubt it), that we need a branch during
some part of the blocks development. If that happens, we can create a
branch then. But in that case we should have a really good plan about
how to make that branch short lived and possible to merge back in
trunk within a very limited time span.
Just creating a 2.3 or 3.0 branch because we feel that we might need
it and as we have made it before would IMO be a completely unnecessary
waste of community resources.
Now, due to license issues we cannot release any OSGi dependent code
until we have updated to OSGi R4, but that only means that we need to
make sure that classic Cocoon not depend on OSGi APIs and that we
exclude the OSGi stuff from the releases. This is probably a good
thing to do anyway, and very little work comparing to keep two
branches synchronized.
With Carsten's proposal to release every two months, we're almost
back into release early, release often, but, problem is, we'd be
releasing a branch often, which is seriously broken, IMO.
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.
--- o0o ---
Remember, open source code becomes stable when many people use it.
Creating development branches destabilizes the code as much fewer, if
any people, use it. And after having destabilized it, it takes much
resources and time to get it releasable again, and at the same time we
have to support the old stable release. All this is a frustrating and
a huge waste of resources, with no particular gain.
So, let us stop the branching madness and work towards having only
*one* common branch (the trunk), that we do the releases from.
I'm quite happy with this approach.
me too!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [2.2] Using includes in the sitemap for components?
Done. I think we should move all sitemap components, even the core ones into included files. This allows to have your application specific sitemap without worrying how to merge this when you update Cocoon. I'll try to minimize the need for patching the web.xml in the next days as well. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Done. Cool! Thinking about it, shouldn't it be COB-INF (or did we decide BLOCK-INF?) rather than WEB-INF, in the blocks. The sitemap-additions and conf will be part of real blocks as well AFAICS. I think we should move all sitemap components, even the core ones into included files. Yes This allows to have your application specific sitemap without worrying how to merge this when you update Cocoon. I'll try to minimize the need for patching the web.xml in the next days as well. Great. /Daniel
Re: [2.2] Using includes in the sitemap for components?
Daniel Fagerstrom wrote: Thinking about it, shouldn't it be COB-INF (or did we decide BLOCK-INF?) rather than WEB-INF, in the blocks. The sitemap-additions and conf will be part of real blocks as well AFAICS. Hmm, currently we have one WEB-INF directory where all configs are added to (in xconf and sitemap-additions). With real blocks we have several blocks and each block has a something-INF directory I think. So as soon as we have real blocks, this will change. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Done. I think we should move all sitemap components, even the core ones into included files. This allows to have your application specific sitemap without worrying how to merge this when you update Cocoon. I'll try to minimize the need for patching the web.xml in the next days as well. On that note, we shouldn't store application configuration in web.xml. web.xml is an environment specific configuration file. The only config that goes there is environment specific configuration. We should store the config that is currently in there in some environmentally neutral file - the obvious one is cocoon.xconf, but, that it isn't in web.xml is more important. This would make the CLI easier. Also, the core Cocoon block in an OSGi system is environment independent, it is the webapp bundle that provides the specific environment, so storing core Cocoon configs in web.xml is problematic there. Thoughs? Upayavira smime.p7s Description: S/MIME Cryptographic Signature
Re: [2.2] Using includes in the sitemap for components?
Upayavira wrote: On that note, we shouldn't store application configuration in web.xml. web.xml is an environment specific configuration file. The only config that goes there is environment specific configuration. We should store the config that is currently in there in some environmentally neutral file - the obvious one is cocoon.xconf, but, that it isn't in web.xml is more important. This would make the CLI easier. Also, the core Cocoon block in an OSGi system is environment independent, it is the webapp bundle that provides the specific environment, so storing core Cocoon configs in web.xml is problematic there. It's already implemented in 2.2 and works :) I used the famous properties format for this, so you can define a property file with all the settings from web.xml and don't need any init parameters in web.xml at all. And of course the CLI can use the same property file. And you can simply override values on startup by specifying the property on the command line. Just a silly example: the cocoon.xconf is at WEB-INF, now you have a debug xconf for debugging, now you can startup Cocoon with cocoon -Dconfiguration=mydebug.xconf and that's it. I'm planning to extend this mechanism in the next days, so every block can have it's own file. I wrote an introduction to this some months ago, but at that time noone really was interested in it :( Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Thinking about it, shouldn't it be COB-INF (or did we decide BLOCK-INF?) rather than WEB-INF, in the blocks. The sitemap-additions and conf will be part of real blocks as well AFAICS. Hmm, currently we have one WEB-INF directory where all configs are added to (in xconf and sitemap-additions). With real blocks we have several blocks and each block has a something-INF directory I think. So as soon as we have real blocks, this will change. I have something like this in mind: /myblock pom.xml /META-INF Manifest.mf /COB-INF block.xml /xconf ... /sitemap-aditions ... /java ... /webapp sitemap.xmap ... For the compile time blocks the content of COB-INF/[xconf|sitemap-additions] are added to the appropriate place in the global webapp/WEB-INF/[xconf|sitemap-additions], like you just have fixed. For real blocks the block.xml points to webapp/sitemap.xmap and COB-INF/xconf/myblock.xconf, and sitemap.xmap in turn includes COB-INF/sitemap-additions/myblock.xconf, and no copying anymore. The point is, that with a layout like the one above (or an improved one), we don't need to change anything, just add the block.xml and Manifest.mf for real blocks. Now, IMHO, it is no big deal if we use WEB-INF instead of COB-INF for the real blocks, but we decided COB-INF once, so we could as well stick with it. /Daniel
Re: [2.2] Using includes in the sitemap for components?
Daniel Fagerstrom wrote: I have something like this in mind: /myblock pom.xml /META-INF Manifest.mf /COB-INF block.xml /xconf ... /sitemap-aditions ... /java ... /webapp sitemap.xmap ... For the compile time blocks the content of COB-INF/[xconf|sitemap-additions] are added to the appropriate place in the global webapp/WEB-INF/[xconf|sitemap-additions], like you just have fixed. For real blocks the block.xml points to webapp/sitemap.xmap and COB-INF/xconf/myblock.xconf, and sitemap.xmap in turn includes COB-INF/sitemap-additions/myblock.xconf, and no copying anymore. The point is, that with a layout like the one above (or an improved one), we don't need to change anything, just add the block.xml and Manifest.mf for real blocks. Now, IMHO, it is no big deal if we use WEB-INF instead of COB-INF for the real blocks, but we decided COB-INF once, so we could as well stick with it. Oh yes, I totally agree with you - my point is just: we can't do this *now* as our ant based build system just copies files and folders. Once we have this m2 running and our own deploy plugin... Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: I have something like this in mind: /myblock pom.xml /META-INF Manifest.mf /COB-INF block.xml /xconf ... /sitemap-aditions ... /java ... /webapp sitemap.xmap ... For the compile time blocks the content of COB-INF/[xconf|sitemap-additions] are added to the appropriate place in the global webapp/WEB-INF/[xconf|sitemap-additions], like you just have fixed. For real blocks the block.xml points to webapp/sitemap.xmap and COB-INF/xconf/myblock.xconf, and sitemap.xmap in turn includes COB-INF/sitemap-additions/myblock.xconf, and no copying anymore. The point is, that with a layout like the one above (or an improved one), we don't need to change anything, just add the block.xml and Manifest.mf for real blocks. Now, IMHO, it is no big deal if we use WEB-INF instead of COB-INF for the real blocks, but we decided COB-INF once, so we could as well stick with it. Oh yes, I totally agree with you - my point is just: we can't do this *now* as our ant based build system just copies files and folders. Once we have this m2 running and our own deploy plugin... Ok, I missed the ant aspect of it, then we wait. And I use WEB-INF instead of COB-INF for the real blocks stuff for the time beeing. /Daniel
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Done. I think we should move all sitemap components, even the core ones into included files. This allows to have your application specific sitemap without worrying how to merge this when you update Cocoon. Great! I'll try to minimize the need for patching the web.xml in the next days as well. How do you plan to do this? We cannot add ourselves an include mechanism in web.xml :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.2] Using includes in the sitemap for components?
Sylvain Wallez wrote: I'll try to minimize the need for patching the web.xml in the next days as well. How do you plan to do this? We cannot add ourselves an include mechanism in web.xml :-) Oh, yes we *can* - we simply take Geronimo and require all users to use that and then we can patch our extensions into the servlet spec and finally get it right :) (Ok, this is just a joke) Now more seriously, it's already there. All the settings stuff I did in the core is just for this. We use POPFs :) (plain old property files) for this. See [1] for the introduction. Now I'm thinking of extending that mechanism to include several block specific property files. See also my response to Upayavira [2] which should show that using properties enables a lot of nice things. (Hopefully I succeeded there). And all this is still compatible with the 2.1.x way of doing things! Carsten [1] http://marc.theaimsgroup.com/?t=11085748025r=1w=2 [2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112556211916690w=2 -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Sylvain Wallez wrote: I'll try to minimize the need for patching the web.xml in the next days as well. How do you plan to do this? We cannot add ourselves an include mechanism in web.xml :-) Oh, yes we *can* - we simply take Geronimo and require all users to use that and then we can patch our extensions into the servlet spec and finally get it right :) (Ok, this is just a joke) Now more seriously, it's already there. All the settings stuff I did in the core is just for this. We use POPFs :) (plain old property files) for this. POPF: I like this :-) See [1] for the introduction. Now I'm thinking of extending that mechanism to include several block specific property files. That was the point. We have a property lookup path, what we need now is this path to be able to include a dynamic set of property files, e.g. WEB-INF/block-*.properties. See also my response to Upayavira [2] which should show that using properties enables a lot of nice things. (Hopefully I succeeded there). And all this is still compatible with the 2.1.x way of doing things! Yup. And that can be a real bonus with OSGi where a bundle can expose these properties as its configufation, meaning the block will contain its complicated xconf file but only expose to the user those parts whose configuration really makes sense, such as paths, jdbc urls, simple boolean flags, etc. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.2] Using includes in the sitemap for components?
Sylvain Wallez wrote: That was the point. We have a property lookup path, what we need now is this path to be able to include a dynamic set of property files, e.g. WEB-INF/block-*.properties. Exactly - I'll do this either today or tomorrow. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Daniel Fagerstrom wrote: I have something like this in mind: /myblock /COB-INF block.xml /sitemap-aditions /webapp sitemap.xmap The block A which depends on block B will have access to: * Exported Java classes of block A * Components of block A * Sitemap components of block A (third bullet here is repeating second, but it's here for clarity). Given the above, what is the point of 'sitemap-additions'? For real blocks the block.xml points to webapp/sitemap.xmap and COB-INF/xconf/myblock.xconf, and sitemap.xmap in turn includes COB-INF/sitemap-additions/myblock.xconf, and no copying anymore. Or, you simply mean, block's sitemap.xmap will import /COB-INF/sitemap-additions/* into itself? If that is so, then again, what is the point in doing it? :) PS Suggestion, rename 'sitemap-additions' to 'xmap' for consistency... Vadim
Re: [2.2] Using includes in the sitemap for components?
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: I have something like this in mind: /myblock /COB-INF block.xml /sitemap-aditions /webapp sitemap.xmap The block A which depends on block B will have access to: * Exported Java classes of block A * Components of block A * Sitemap components of block A (third bullet here is repeating second, but it's here for clarity). Given the above, what is the point of 'sitemap-additions'? Components are included in the cocoon.xconf and sitemap components in the component section in the main sitemap.xmap. Is there a point of doing it this way? I don't know, if the sitemap components still must be declared within a sitemap there might be, otherwise not. For real blocks the block.xml points to webapp/sitemap.xmap and COB-INF/xconf/myblock.xconf, and sitemap.xmap in turn includes COB-INF/sitemap-additions/myblock.xconf, and no copying anymore. Or, you simply mean, block's sitemap.xmap will import /COB-INF/sitemap-additions/* into itself? Yes. If that is so, then again, what is the point in doing it? :) See above. So, if sitemap components doesn't need to be defined within a sitemap anymore, I agree with you that we should skip the sitemap additions and put everything in the blocks xconf. Then all blocks both such that has a sitemap and such that only exports components would have a root component manager with all components from the blocks xconf in it. For blocks that also have a sitemap the root component manager would be pararent component manager for the sitemap. If sitemap components really need to be part of a sitemap it is a question what it would mean to export such a component from a block. Thoughts? /Daniel
Re: [2.2] Using includes in the sitemap for components?
Daniel Fagerstrom wrote: Vadim Gritsenko wrote: snips everywhere/ The block A which depends on block B will have access to: * Sitemap components of block A Given the above, what is the point of 'sitemap-additions'? Components are included in the cocoon.xconf and sitemap components in the component section in the main sitemap.xmap. 'main sitemap'? Sitemap components - see above - are included in the block's sitemap.xmap, not in the main one - not in the Cocoon's root sitemap. May be you meant block's main sitemap... Is there a point of doing it this way? I don't know, if the sitemap components still must be declared within a sitemap there might be, otherwise not. Strictly speaking, there is no must here... We could easily merge block's xconf and xmap into single file. For real blocks the block.xml points to webapp/sitemap.xmap and COB-INF/xconf/myblock.xconf, and sitemap.xmap in turn includes COB-INF/sitemap-additions/myblock.xconf, and no copying anymore. Or, you simply mean, block's sitemap.xmap will import /COB-INF/sitemap-additions/* into itself? Yes. If that is so, then again, what is the point in doing it? :) See above. Above does not explain the need :-) Currently with huge root sitemap we have a need; but given block's sitemap will have few sitemap components to declare - why separate them into yet another file? So, if sitemap components doesn't need to be defined within a sitemap anymore, Actually, it's not required. I agree with you that we should skip the sitemap additions and put everything in the blocks xconf. I suggest the revers: put everything from block's xconf into its xmap :-) Then all blocks both such that has a sitemap and such that only exports components would have a root component manager with all components from the blocks xconf in it. ... from the sitemap.xmap in it :-) For blocks that also have a sitemap the root component manager would be pararent component manager for the sitemap. If sitemap components really need to be part of a sitemap it is a question what it would mean to export such a component from a block. Thoughts? At the end, either way will do. Vadim
Re: [2.2] Using includes in the sitemap for components?
Vadim Gritsenko wrote:
I suggest the revers: put everything from block's xconf into its xmap :-)
If there is no technical reasons that speak against it, I would really welcome
this merge. (... and people that like to have two files, can use the include
mechanism)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [2.2] Using includes in the sitemap for components?
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: ... I agree with you that we should skip the sitemap additions and put everything in the blocks xconf. I suggest the revers: put everything from block's xconf into its xmap :-) Then all blocks both such that has a sitemap and such that only exports components would have a root component manager with all components from the blocks xconf in it. ... from the sitemap.xmap in it :-) For blocks that also have a sitemap the root component manager would be pararent component manager for the sitemap. If sitemap components really need to be part of a sitemap it is a question what it would mean to export such a component from a block. Thoughts? At the end, either way will do. We agree about merging components and sitemap components to one configuration file. You suggest that it is included in the block sitemap and that the components of the blocks sitemap is exported so that other blocks can use it. What I'm thinking about is that we will have blocks that export sitemap functionality and components and bloks that just exports blocks or sitemap functionality (but not both). Current blocks have the main task to export components, but they also export sitemap functionality in terns of samples. Now for sitemap and sitemap+component exporting blocks your proposal is fine but for blocks that only export components (which will be a common case when we factor out the sample from the blocks) having a sitemap that only includes components does not make tha much sense to me. What I propose is that the block descriptor block.xml contains both a sitemap path (as it has today) and a component configuration path(s) (a new addition) both optional. Then a block with a component configuration path will create a root component manager where everything from the component configuration is exported. If there also is a sitemap path, the sitemap processor will use the root component manager as parent component manager. If there is a sitemap configuration path but no component configuration path the block will not export any components. I prefer the described solution partly because a sitemap configuration IMO not make sense for component only blocks and partly because it provide a very smooth evolutionary path towards real blocks. The blocks can look like today, only a block.xml with paths to the current component configuration pat, main sitemap etc and a Manifest.mf is needed. /Daniel
Re: [2.2] Using includes in the sitemap for components?
Daniel Fagerstrom wrote:
What I propose is that the block descriptor block.xml contains both a
sitemap path (as it has today) and a component configuration path(s) (a
new addition) both optional.
This makes sense - now I also remember that you've already explained this to me
in Stuttgart :-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [2.2] Using includes in the sitemap for components?
I haven't looked at the code for this, but a) I'd love it in 2.1 and b) is it pluggable? We already have an XML file with some configuration in it including some system properties that need to be set. It would be nice if I could leverage the same file for this. Ralph Carsten Ziegeler wrote: It's already implemented in 2.2 and works :) I used the famous properties format for this, so you can define a property file with all the settings from web.xml and don't need any init parameters in web.xml at all. And of course the CLI can use the same property file. And you can simply override values on startup by specifying the property on the command line. Just a silly example: the cocoon.xconf is at WEB-INF, now you have a debug xconf for debugging, now you can startup Cocoon with cocoon -Dconfiguration=mydebug.xconf and that's it. I'm planning to extend this mechanism in the next days, so every block can have it's own file. I wrote an introduction to this some months ago, but at that time noone really was interested in it :( Carsten
Re: [2.2] Using includes in the sitemap for components?
Daniel Fagerstrom wrote: What I propose is that the block descriptor block.xml contains both a sitemap path (as it has today) and a component configuration path(s) (a new addition) both optional. Then a block with a component configuration path will create a root component manager where everything from the component configuration is exported. If there also is a sitemap path, the sitemap processor will use the root component manager as parent component manager. If there is a sitemap configuration path but no component configuration path the block will not export any components. I prefer the described solution partly because a sitemap configuration IMO not make sense for component only blocks and partly because it provide a very smooth evolutionary path towards real blocks. The blocks can look like today, only a block.xml with paths to the current component configuration pat, main sitemap etc and a Manifest.mf is needed. Ok, sounds good. Vadim
[2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Can't this be handled by wildcard inclusion from component configurations in some catalog, so that we get rid of the snippet insertions. SNIP/ We can use wildcard inclusion in the main sitemap as well. So what do others think? Do we want to get away of patching the main sitemap? I think we should add an include statement for the main sitemap that includes additional sitemap components from some directory in the WEB-INF dir, like WEB-INF/sitemap-components/*.xconf Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Can't this be handled by wildcard inclusion from component configurations in some catalog, so that we get rid of the snippet insertions. SNIP/ We can use wildcard inclusion in the main sitemap as well. So what do others think? Do we want to get away of patching the main sitemap? I think we should add an include statement for the main sitemap that includes additional sitemap components from some directory in the WEB-INF dir, like WEB-INF/sitemap-components/*.xconf Oh yes, for sure! The more we can avoid xpatch the better IMO. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [2.2] Using includes in the sitemap for components?
Le 31 août 05, à 08:51, Carsten Ziegeler a écrit : ...I think we should add an include statement for the main sitemap that includes additional sitemap components from some directory in the WEB-INF dir, like WEB-INF/sitemap-components/*.xconf.. agreed, and it would be good to have debug messages to allow one to see exactly which files are being included (if that's not the case already). -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [2.2] Using includes in the sitemap for components?
Carsten Ziegeler wrote: So what do others think? Do we want to get away of patching the main sitemap? I think we should add an include statement for the main sitemap that includes additional sitemap components from some directory in the WEB-INF dir, like WEB-INF/sitemap-components/*.xconf +1 Carsten
Re: [2.2] Using includes in the sitemap for components?
Sylvain Wallez wrote: Carsten Ziegeler wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Can't this be handled by wildcard inclusion from component configurations in some catalog, so that we get rid of the snippet insertions. SNIP/ We can use wildcard inclusion in the main sitemap as well. So what do others think? Do we want to get away of patching the main sitemap? I think we should add an include statement for the main sitemap that includes additional sitemap components from some directory in the WEB-INF dir, like WEB-INF/sitemap-components/*.xconf Oh yes, for sure! The more we can avoid xpatch the better IMO. +1 -- Stefano.
